When 10 minutes before midnight is out of range.

[Dennis D.]

VB.net does not seem to have adequate structure for handling time
within it's own code.
Subtract 15 minutes from 00:00 AM, and an out of range condition results.
Subtract 15 minutes from 12:00 PM, and the result is 11:45 AM,
as it should be.
Seems one half of the process is missing, and it is the half that requires
the most thought. Without it, we are left to hand code the whole process.
Time has a standard, and it should be properly implemented in the language.
Time is also one of the most commonly used routines in programming.
While I could work around the VB time construct programmatically, I feel
that the issue should be addressed. At least it should work with local time,
with only UTC conversion requiring additional code.

Why is it the way it is?

Here's the code:

Private Sub btnAction_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles btnAction.Click
'begin StartText
Dim StartText As String = txbStart.Text
Dim HourParse As String = Mid(StartText, 1, 2)
Dim HourDbl As Double = Val(HourParse)
Dim HourInt As Integer = CInt(HourDbl)
Dim MinParse As String = Mid(StartText, 4, 2)
Dim MinDbl As Double = Val(MinParse)
Dim MinInt As Integer = CInt(MinDbl)
Dim SecInt As Integer = 0
Dim FunctionTime As Date = TimeSerial(HourInt, MinInt, SecInt)
Dim StartLabelText As String = Format(FunctionTime, "hh:mm tt")
'Set Start Time Label
lblStartUpR.Text = StartLabelText
'end StartText
'begin PreStart
Dim PreStart As String = txbPreStart.Text
HourParse = Mid(PreStart, 1, 2)
HourDbl = Val(HourParse)
HourInt = CInt(HourDbl)
MinParse = Mid(PreStart, 4, 2)
MinDbl = Val(MinParse)
MinInt = CInt(MinDbl)
'Begin Calc
Dim MinusHour As Double = HourDbl * -1
Dim MinusMin As Double = MinDbl * -1
Dim PreStartHour As Date = DateAdd(DateInterval.Hour, MinusHour,
CDate(txbStart.Text))
Dim PreStartHourDbl As Double = Val(PreStartHour)
Dim PreStartHourInt As Integer = CInt(PreStartHourDbl)
Dim PreStartMin As Date = DateAdd(DateInterval.Minute, MinusMin,
CDate(txbStart.Text))
Dim PreStartMinDbl As Double = Val(PreStartMin)
Dim PreStartInt As Integer = CInt(PreStartMinDbl)
FunctionTime = TimeSerial(HourInt, MinInt, SecInt)
StartLabelText = Format(FunctionTime, "hh:mm tt")
lblArrivalR.Text = PreStartMin.ToShortTimeString
End Sub

txbStart is a textbox. The time is entered in 24hour format as hh:mm.
lblStartUpR is a label that displays the time in short time format

txbPreStart is a textbox taking the same format.
lblArrivalR is a label that displays the time in short time format that is a
result of the following calculation:

txbPreStart is subtracted (by addition of a minus value) from txbStart

'Should I write simpler and tighter code to throw the exception?

[Armin Zingler]

"Dennis D." <te**@dennisys.com> schrieb

VB.net does not seem to have adequate structure for handling time
within it's own code.
Subtract 15 minutes from 00:00 AM, and an out of range condition
results. Subtract 15 minutes from 12:00 PM, and the result is 11:45
AM,
as it should be.
Seems one half of the process is missing, and it is the half that
requires the most thought. Without it, we are left to hand code the
whole process. Time has a standard, and it should be properly
implemented in the language. Time is also one of the most commonly
used routines in programming. While I could work around the VB time
construct programmatically, I feel that the issue should be
addressed. At least it should work with local time, with only UTC
conversion requiring additional code.

Why is it the way it is?

You must distinguish between a certain point in time and a Timespan. The
first is expressed by a Date (DateTime) value and the second by a Timespan
(System.TimeSpan) value. The time within a day is also expressed by a
Timespan (the timespan since midnight) as you see by having a look at the
data type of DateTime.TimeOfDay.

A certain point in time is composed of a date and a time. The smallest value
is DateTime.MinValue (01/01/0001 00:00) and the largest ist
DateTime.MaxValue.

So, your fault is to use a DateTime variable to store the time of the day.
When you use

PreStartHour As Date = DateAdd(DateInterval.Hour, MinusHour,
CDate(txbStart.Text))

then you are trying to subtract 1 hour from 01/01/0001 00:00. This is not
possible because this date is already the smallest value possible for a
DateTime structure.

I don't understand the purpose of your procedure, but I suggest to use the
members of the DateTime and TimeSpan structures to convert from/to
String/DateTime/Timespan, like
- DateTime.Parse, DateTime.ParseExact
- DateTime.Add, DateTime.Subtract
- Constructors for DateTime and TimeSpan
- TimeSpan.Add
and all the other members.

Maybe you could describe the purpose of the procedure and I can show you how
I would implement it.
--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Dennis D.]

"Armin Zingler" <az*******@freenet.de> wrote in message
news:40***********************@news.freenet.de...

"Dennis D." <te**@dennisys.com> schrieb

VB.net does not seem to have adequate structure for handling time
within it's own code.
Subtract 15 minutes from 00:00 AM, and an out of range condition
results. Subtract 15 minutes from 12:00 PM, and the result is 11:45
AM,
as it should be.
Seems one half of the process is missing, and it is the half that
requires the most thought. Without it, we are left to hand code the
whole process. Time has a standard, and it should be properly
implemented in the language. Time is also one of the most commonly
used routines in programming. While I could work around the VB time
construct programmatically, I feel that the issue should be
addressed. At least it should work with local time, with only UTC
conversion requiring additional code.

Why is it the way it is?
You must distinguish between a certain point in time and a Timespan. The
first is expressed by a Date (DateTime) value and the second by a Timespan
(System.TimeSpan) value. The time within a day is also expressed by a
Timespan (the timespan since midnight) as you see by having a look at the
data type of DateTime.TimeOfDay.

A certain point in time is composed of a date and a time. The smallest

value is DateTime.MinValue (01/01/0001 00:00) and the largest ist
DateTime.MaxValue.

So, your fault is to use a DateTime variable to store the time of the day.
When you use

PreStartHour As Date = DateAdd(DateInterval.Hour, MinusHour,
CDate(txbStart.Text))

then you are trying to subtract 1 hour from 01/01/0001 00:00. This is not
possible because this date is already the smallest value possible for a
DateTime structure.

I don't understand the purpose of your procedure, but I suggest to use the
members of the DateTime and TimeSpan structures to convert from/to
String/DateTime/Timespan, like
- DateTime.Parse, DateTime.ParseExact
- DateTime.Add, DateTime.Subtract
- Constructors for DateTime and TimeSpan
- TimeSpan.Add
and all the other members.

Maybe you could describe the purpose of the procedure and I can show you how I would implement it.
--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

That's my point exactly.
A date is assumed, or you must give the program a date
(as January 01, 2001).
But when is not 00:00 minus 00:15 not 23:45 on a
24 hour clock? It is always 23:45!
So why go through all this code to arrive at a simple fact?
It should require 2 lines of code at worst to say:
00:00 - 00:15 == 23:45
Because at this point no one has assumed anything.
No one has said Daylight savings, or past the Prime Meridian.
If I wanted to specifiy something extra, such as DST or UTC,
then I could understand the difficulty of being required to
provide more information.
But a time type should have some simple unassuming
assumptions, that if you move past the negative boundry it
subtracts one unit from the parent, whatever that is.
0 - 1 = -1, how difficult is that?
In time: 00:00 - 00:15 = 23:45, or
00:00 - 01:01 = 23:59, seems simple enough to me.
That's not how it works?
I know.
That is why I am recommending action.
A high level language shouldn't have a problem with this.

[Dennis D.]

oops: 00:00 - 01:01 = 22:59
I think. Brain Fart!

"Dennis D." <te**@dennisys.com> wrote in message
news:eY**************@TK2MSFTNGP12.phx.gbl...

"Armin Zingler" <az*******@freenet.de> wrote in message
news:40***********************@news.freenet.de...

"Dennis D." <te**@dennisys.com> schrieb

VB.net does not seem to have adequate structure for handling time
within it's own code.
Subtract 15 minutes from 00:00 AM, and an out of range condition
results. Subtract 15 minutes from 12:00 PM, and the result is 11:45
AM,
as it should be.
Seems one half of the process is missing, and it is the half that
requires the most thought. Without it, we are left to hand code the
whole process. Time has a standard, and it should be properly
implemented in the language. Time is also one of the most commonly
used routines in programming. While I could work around the VB time
construct programmatically, I feel that the issue should be
addressed. At least it should work with local time, with only UTC
conversion requiring additional code.

Why is it the way it is?

You must distinguish between a certain point in time and a Timespan. The
first is expressed by a Date (DateTime) value and the second by a Timespan (System.TimeSpan) value. The time within a day is also expressed by a
Timespan (the timespan since midnight) as you see by having a look at the data type of DateTime.TimeOfDay.

A certain point in time is composed of a date and a time. The smallest

value

is DateTime.MinValue (01/01/0001 00:00) and the largest ist
DateTime.MaxValue.

So, your fault is to use a DateTime variable to store the time of the day. When you use

PreStartHour As Date = DateAdd(DateInterval.Hour, MinusHour,
CDate(txbStart.Text))

then you are trying to subtract 1 hour from 01/01/0001 00:00. This is not possible because this date is already the smallest value possible for a
DateTime structure.

I don't understand the purpose of your procedure, but I suggest to use the members of the DateTime and TimeSpan structures to convert from/to
String/DateTime/Timespan, like
- DateTime.Parse, DateTime.ParseExact
- DateTime.Add, DateTime.Subtract
- Constructors for DateTime and TimeSpan
- TimeSpan.Add
and all the other members.

Maybe you could describe the purpose of the procedure and I can show you

how

I would implement it.
--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

That's my point exactly.
A date is assumed, or you must give the program a date
(as January 01, 2001).
But when is not 00:00 minus 00:15 not 23:45 on a
24 hour clock? It is always 23:45!
So why go through all this code to arrive at a simple fact?
It should require 2 lines of code at worst to say:
00:00 - 00:15 == 23:45
Because at this point no one has assumed anything.
No one has said Daylight savings, or past the Prime Meridian.
If I wanted to specifiy something extra, such as DST or UTC,
then I could understand the difficulty of being required to
provide more information.
But a time type should have some simple unassuming
assumptions, that if you move past the negative boundry it
subtracts one unit from the parent, whatever that is.
0 - 1 = -1, how difficult is that?
In time: 00:00 - 00:15 = 23:45, or
00:00 - 01:01 = 23:59, seems simple enough to me.
That's not how it works?
I know.
That is why I am recommending action.
A high level language shouldn't have a problem with this.

[Armin Zingler]

"Dennis D." <te**@dennisys.com> schrieb

IMO your logical approach is not completely correct. You're saying that
00:00 - 01:01 = 22:59. That's only 1/2 truth. The whole truth is that it is
"22:59 the day before". This can be expressed by a Timespan:

dim ts as new timespan
ts = ts.subtract(new timespan(1, 1, 0)) '00:00
msgbox ts.tostring '=> -01:01:00

What would happen if you subtract 25 hours and 1 minute? Your result would
*also* be 22:59. So, subtracting 1 hour or subtracting 25 hours would lead
to the *same* result? I don't think it is correct because you are ignoring
the day. Do you really want to ignore the day? I'm almost sure you can't
because there will probably any calculation using the result of the
subtraction. Won't it? What are you going to do with the result of the
subtraction?

--
Armin

oops: 00:00 - 01:01 = 22:59
I think. Brain Fart!

"Dennis D." <te**@dennisys.com> wrote in message
news:eY**************@TK2MSFTNGP12.phx.gbl...

"Armin Zingler" <az*******@freenet.de> wrote in message
news:40***********************@news.freenet.de...

"Dennis D." <te**@dennisys.com> schrieb
> VB.net does not seem to have adequate structure for handling
> time
> within it's own code.
> Subtract 15 minutes from 00:00 AM, and an out of range
> condition results. Subtract 15 minutes from 12:00 PM, and the
> result is 11:45 AM,
> as it should be.
> Seems one half of the process is missing, and it is the half
> that requires the most thought. Without it, we are left to hand
> code the whole process. Time has a standard, and it should be
> properly implemented in the language. Time is also one of the
> most commonly used routines in programming. While I could work
> around the VB time construct programmatically, I feel that the
> issue should be addressed. At least it should work with local
> time, with only UTC conversion requiring additional code.
>
> Why is it the way it is?

You must distinguish between a certain point in time and a
Timespan. The first is expressed by a Date (DateTime) value and
the second by a Timespan (System.TimeSpan) value. The time within a day is also expressed
by a Timespan (the timespan since midnight) as you see by having
a look at the data type of DateTime.TimeOfDay.

A certain point in time is composed of a date and a time. The
smallest

value

is DateTime.MinValue (01/01/0001 00:00) and the largest ist
DateTime.MaxValue.

So, your fault is to use a DateTime variable to store the time of
the day. When you use

PreStartHour As Date = DateAdd(DateInterval.Hour, MinusHour,
CDate(txbStart.Text))

then you are trying to subtract 1 hour from 01/01/0001 00:00.
This is not possible because this date is already the smallest value possible
for a DateTime structure.

I don't understand the purpose of your procedure, but I suggest
to use the members of the DateTime and TimeSpan structures to convert
from/to String/DateTime/Timespan, like
- DateTime.Parse, DateTime.ParseExact
- DateTime.Add, DateTime.Subtract
- Constructors for DateTime and TimeSpan
- TimeSpan.Add
and all the other members.

Maybe you could describe the purpose of the procedure and I can
show you

how

I would implement it.
--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

That's my point exactly.
A date is assumed, or you must give the program a date
(as January 01, 2001).
But when is not 00:00 minus 00:15 not 23:45 on a
24 hour clock? It is always 23:45!
So why go through all this code to arrive at a simple fact?
It should require 2 lines of code at worst to say:
00:00 - 00:15 == 23:45
Because at this point no one has assumed anything.
No one has said Daylight savings, or past the Prime Meridian.
If I wanted to specifiy something extra, such as DST or UTC,
then I could understand the difficulty of being required to
provide more information.
But a time type should have some simple unassuming
assumptions, that if you move past the negative boundry it
subtracts one unit from the parent, whatever that is.
0 - 1 = -1, how difficult is that?
In time: 00:00 - 00:15 = 23:45, or
00:00 - 01:01 = 23:59, seems simple enough to me.
That's not how it works?
I know.
That is why I am recommending action.
A high level language shouldn't have a problem with this.

[Cor Ligthert]

Hi Armin,

First time I see you in this newsgroup.

Did you see that Dennis told he saw it wrong?

Cor

[Armin Zingler]

"Cor Ligthert" <no**********@planet.nl> schrieb

Hi Armin,

First time I see you in this newsgroup.

Did you see that Dennis told he saw it wrong?

No, Cor. I read his post now again, but I dont' see it. What do you mean?
--
Armin

[Cor Ligthert]

Hi Armin,

By Dennis as answer on his own message which was an answer to you.

oops: 00:00 - 01:01 = 22:59
I think. Brain Fart!

Although your message is of course a good addition.

Cor

[Dennis D.]

"Armin Zingler" <az*******@freenet.de> wrote in message
news:40***********************@news.freenet.de...

"Dennis D." <te**@dennisys.com> schrieb
What are you going to do with the result of the subtraction?

Ever notice that most clocks do not have day or date features?
So why should an object oriented programming language that types a time
function ignore that fact, and require a date?

[Cor Ligthert]

Hi Dennis,

Exacly here you show the superiority of human on a computer.

Ever notice that most clocks do not have day or date features?
So why should an object oriented programming language that types a time
function ignore that fact, and require a date?

We do not have to know that, millions years of evolution have learned us the
changing of the day.

However the clock is not such a natural thing and now we need a clock for
that to try to get those times.

Here a link for that

http://www.ernie.cummings.net/clock.htm

Just my thought,

Cor

[Armin Zingler]

"Dennis D." <te**@dennisys.com> schrieb

"Armin Zingler" <az*******@freenet.de> wrote in message
news:40***********************@news.freenet.de...

"Dennis D." <te**@dennisys.com> schrieb

What are you going to do with the result of the

subtraction?

Ever notice that most clocks do not have day or date features?
So why should an object oriented programming language that types a
time function ignore that fact, and require a date?

On which clock do you subtract hours? Even if you can, there are two cases:
Either you can only subtract a maximum of 1 day, or you can subtract more
than 24 hours.
The former case: Simply add 24 hours if the result is <0, that's what the
clock also would have to do, not to get negative values.
The latter case: There must be a date somewhere, otherwise subtracting 1
hour or 25 hours would be the same.
Dim ts As New TimeSpan
ts = ts.Subtract(New TimeSpan(1, 1, 0))
If ts.Ticks < 0 Then
ts = ts.Add(New TimeSpan(-ts.Days + 1, 0, 0, 0))
End If
MsgBox(ts.Hours.ToString("00") & ":" & ts.Minutes.ToString("00"))

I would agree that the Timespan's ToString method should be overloaded and
accept a format string.

--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Dennis D.]

Thanks Armin, Cor:

Have a great day!

Dennis,
http://www.dennisys.com/

"Dennis D." <te**@dennisys.com> wrote in message
news:eg*************@TK2MSFTNGP12.phx.gbl...

"Armin Zingler" <az*******@freenet.de> wrote in message
news:40***********************@news.freenet.de...

"Dennis D." <te**@dennisys.com> schrieb

What are you going to do with the result of the

subtraction?

Ever notice that most clocks do not have day or date features?
So why should an object oriented programming language that types a time
function ignore that fact, and require a date?