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 programmaticall y, 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.EventArg s) 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(Hour Int, MinInt, SecInt)
Dim StartLabelText As String = Format(Function Time, "hh:mm tt")
'Set Start Time Label
lblStartUpR.Tex t = StartLabelText
'end StartText
'begin PreStart
Dim PreStart As String = txbPreStart.Tex t
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(DateInt erval.Hour, MinusHour,
CDate(txbStart. Text))
Dim PreStartHourDbl As Double = Val(PreStartHou r)
Dim PreStartHourInt As Integer = CInt(PreStartHo urDbl)
Dim PreStartMin As Date = DateAdd(DateInt erval.Minute, MinusMin,
CDate(txbStart. Text))
Dim PreStartMinDbl As Double = Val(PreStartMin )
Dim PreStartInt As Integer = CInt(PreStartMi nDbl)
FunctionTime = TimeSerial(Hour Int, MinInt, SecInt)
StartLabelText = Format(Function Time, "hh:mm tt")
lblArrivalR.Tex t = PreStartMin.ToS hortTimeString
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 programmaticall y, 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.TimeSpa n) 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.TimeOf Day.

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

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

PreStartHour As Date = DateAdd(DateInt erval.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.ParseE xact
- DateTime.Add, DateTime.Subtra ct
- 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*******@free net.de> wrote in message
news:40******** *************** @news.freenet.d e...

"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 programmaticall y, 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.TimeSpa n) 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.TimeOf Day.

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

value is DateTime.MinVal ue (01/01/0001 00:00) and the largest ist
DateTime.MaxVal ue.

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

PreStartHour As Date = DateAdd(DateInt erval.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.ParseE xact
- DateTime.Add, DateTime.Subtra ct
- 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******** ******@TK2MSFTN GP12.phx.gbl...

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

"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 programmaticall y, 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.TimeSpa n) 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.TimeOf Day.

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

value

is DateTime.MinVal ue (01/01/0001 00:00) and the largest ist
DateTime.MaxVal ue.

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

PreStartHour As Date = DateAdd(DateInt erval.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.ParseE xact
- DateTime.Add, DateTime.Subtra ct
- 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******** ******@TK2MSFTN GP12.phx.gbl...

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

"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 programmaticall y, 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.TimeSpa n) 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.TimeOf Day.

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

value

is DateTime.MinVal ue (01/01/0001 00:00) and the largest ist
DateTime.MaxVal ue.

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

PreStartHour As Date = DateAdd(DateInt erval.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.ParseE xact
- DateTime.Add, DateTime.Subtra ct
- 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**********@p lanet.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*******@free net.de> wrote in message
news:40******** *************** @news.freenet.d e...

"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