Hi friend, take the following simple code
It raises the exception:
The supplied DateTime represents an invalid time. For example,
when the clock is adjusted forward, any time in the period that is
skipped is invalid.
Parameter name: dateTime

Could i have some enlightening on this? (should be related with
daylight)
And how should i modify my loop to proceed normally in the generation
of new dates avoiding the error ?
[BTW i am generating time series of random prices, this is time, the
"x" axis]

--------------------------
Public TimeZoneInfo_LOCAL As TimeZoneInfo = TimeZoneInfo.Local
Public TimeZoneInfo_EDT As TimeZoneInfo =
TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time")
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles Button1.Click
Dim d As New Date(2011, 3, 1)
Do
Dim NewDate = d.AddMinutes(1)
Dim NewDate_loc As Date =
TimeZoneInfo.ConvertTime(NewDate, TimeZoneInfo_EDT,
TimeZoneInfo_LOCAL)
d = NewDate
Loop
End Sub
--------------------------

I am looking for a way to have the loop proceed normally generating
the dates
NewDate_loc dates (a gap of 1 hour is fine, no problem).

-Pam

Am 19.03.2011 20:31, schrieb pamela fluente:
> Hi friend, take the following simple code
> It raises the exception:
> The supplied DateTime represents an invalid time. For example,
> when the clock is adjusted forward, any time in the period that is
> skipped is invalid.
> Parameter name: dateTime
>
> Could i have some enlightening on this? (should be related with
> daylight)
> And how should i modify my loop to proceed normally in the generation
> of new dates avoiding the error ?
> [BTW i am generating time series of random prices, this is time, the
> "x" axis]
>
> --------------------------
> Public TimeZoneInfo_LOCAL As TimeZoneInfo = TimeZoneInfo.Local
> Public TimeZoneInfo_EDT As TimeZoneInfo =
> TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time")
> Private Sub Button1_Click(ByVal sender As System.Object, ByVal e
> As System.EventArgs) Handles Button1.Click
> Dim d As New Date(2011, 3, 1)
> Do
> Dim NewDate = d.AddMinutes(1)
> Dim NewDate_loc As Date =
> TimeZoneInfo.ConvertTime(NewDate, TimeZoneInfo_EDT,
> TimeZoneInfo_LOCAL)
> d = NewDate
> Loop
> End Sub
> --------------------------
>
> I am looking for a way to have the loop proceed normally generating
> the dates
> NewDate_loc dates (a gap of 1 hour is fine, no problem).


As you already wrote, due to daylight saving time, not every point in time
is a valid local time. With EST, daylight saving time seems to start at
3/13/2011 2:00:00 AM. If the clock is set 1 hour ahead, the sequence is:

3/13/2011, 01:58 AM
3/13/2011, 01:59 AM
3/13/2011, 03:00 AM
3/13/2011, 03:01 AM

So, if you're trying to convert any time between
3/13/2011, 02:00 AM (inclusive) and 3/13/2011, 03:00 AM (exclusive),
the error occurs. Any point in time in this timespan simply does
not exist in that time zone.


On the other hand, whenever DST ends, there's an ambiguous timespan.
The clock is set back one hour on 11/6/2011, 02:00AM. Consequently the
sequence is

11/6/2011, 01:00 AM
11/6/2011, 01:01 AM
....
11/6/2011, 01:58 AM
11/6/2011, 01:59 AM
11/6/2011, 01:00 AM
11/6/2011, 01:01 AM
11/6/2011, 01:02 AM

You have ambiguous local times within 1 AM and 2 AM. Have a look at
TimeZoneInfo.GetAmbiguousTimeOffsets and the documentation of
TimeZoneInfo.ConvertTime how this is handled. IIRC I read something
about it there.

The resolution is to only work with UTC internally. You can
still display the local time. Or, use DateTimeOffset instead
of DateTime; then it's also always convertible.

--
Armin

Am 19.03.2011 21:14, schrieb Armin Zingler:
> The resolution is to only work with UTC internally. You can
> still display the local time. Or, use DateTimeOffset instead
> of DateTime; then it's also always convertible.

In other words, if you've collected data at 11/6/2011, 01:30 (local time),
how do you know if it was before or after adjusting the clock?
This problem is because you use the DateTime type which is not appropriate
for these purposes. It only says "local time", but it has no offset.
That's why DateTimeOffset has been introduced.


--
Armin

Am 19.03.2011 21:24, schrieb Armin Zingler:
> Am 19.03.2011 21:14, schrieb Armin Zingler:
>> The resolution is to only work with UTC internally. You can
>> still display the local time. Or, use DateTimeOffset instead
>> of DateTime; then it's also always convertible.
>
> In other words, if you've collected data at 11/6/2011, 01:30 (local time),
> how do you know if it was before or after adjusting the clock?
> This problem is because you use the DateTime type which is not appropriate
> for these purposes. It only says "local time", but it has no offset.
> That's why DateTimeOffset has been introduced.

Sorry, me again....
You can still use DateTime, but with Kind=UTC. Then you can associate
your date with these DateTimes.

--
Armin

On 19 Mar, 21:26, Armin Zingler <az.nos...@freenet.de> wrote:
> Am 19.03.2011 21:24, schrieb Armin Zingler:
>
> > Am 19.03.2011 21:14, schrieb Armin Zingler:
> >> The resolution is to only work with UTC internally. You can
> >> still display the local time. Or, use DateTimeOffset instead
> >> of DateTime; then it's also always convertible.
>
> > In other words, if you've collected data at 11/6/2011, 01:30 (local time),
> > how do you know if it was before or after adjusting the clock?
> > This problem is because you use the DateTime type which is not appropriate
> > for these purposes. It only says "local time", but it has no offset.
> > That's why DateTimeOffset has been introduced.
>
> Sorry, me again....
> You can still use DateTime, but with Kind=UTC. Then you can associate
> your date with these DateTimes.
>
> --
> Armin

Thanks a lot Armin. Very helpful.

I am also researching. Looks live using the IsInvalidTime() of the
timezone
i can easily skip on the hour.

Seems to work fine so far. Let me know if you see potential dangers.

-Pam

Am 19.03.2011 21:31, schrieb pamela fluente:
> Thanks a lot Armin. Very helpful.
>
> I am also researching. Looks live using the IsInvalidTime() of the
> timezone
> i can easily skip on the hour.
>
> Seems to work fine so far. Let me know if you see potential dangers.

How do you intend to handle the ambiguous times?

--
Armin

On 19 Mar, 21:42, Armin Zingler <az.nos...@freenet.de> wrote:
> Am 19.03.2011 21:31, schrieb pamela fluente:
>
> > Thanks a lot Armin. Very helpful.
>
> > I am also researching. Looks live using the IsInvalidTime() of the
> > timezone
> > i can easily skip on the hour.
>
> > Seems to work fine so far. Let me know if you see potential dangers.
>
> How do you intend to handle the ambiguous times?
>
> --
> Armin


Thanks a lot Armin. Very insightful.
I am not sure what you mean by ambiguous.

Let me clarify what i am doing, so will be clearer wheter i still
will have problems.

Take and InitialDate. an EDT (est time) date.
Starting form that InitialDate i generate a sequence of (date, price)

The sequence is pretty tight, being the date spaced a few
milliseconds.

The sequence (al est times) run up to another date as to cover N days.

InitialDate ---------------- InitialDate +N days

I use this series for various simulation.

Now while i am plotting this series (x = time y=price) i also
bother, tick by tick, showing what would be the time in LOCAL
timezone.

So i noticed that for some special selection of InitialDate and N i
found this error.
Now, to correct, i am thinking just to skip (in the loop) the invalid
times.


-Pam

Am 19.03.2011 22:09, schrieb pamela fluente:
>>> Seems to work fine so far. Let me know if you see potential dangers.
>>
>> How do you intend to handle the ambiguous times?
>>
>
>
> Thanks a lot Armin. Very insightful.
> I am not sure what you mean by ambiguous.

I mean that for example 11/6/2011, 01:30 AM (local time) occurs twice.


> Let me clarify what i am doing, so will be clearer wheter i still
> will have problems.
>
> Take and InitialDate. an EDT (est time) date.
> Starting form that InitialDate i generate a sequence of (date, price)
>
> The sequence is pretty tight, being the date spaced a few
> milliseconds.
>
> The sequence (al est times) run up to another date as to cover N days.
>
> InitialDate ---------------- InitialDate +N days
>
> I use this series for various simulation.
>
> Now while i am plotting this series (x = time y=price) i also
> bother, tick by tick, showing what would be the time in LOCAL
> timezone.
>
> So i noticed that for some special selection of InitialDate and N i
> found this error.
> Now, to correct, i am thinking just to skip (in the loop) the invalid
> times.

Where does InitialDate come from? Do you verify that it's a valid
and unambiguous time?
I would first convert the initial DateTime to UTC. From there
you can compute the UTC time at every x-position, and from every
UTC time, you can always and unambiguously compute the local time.

--
Armin

On 19 Mar, 22:27, Armin Zingler <az.nos...@freenet.de> wrote:
> Am 19.03.2011 22:09, schrieb pamela fluente:
>
> >>> Seems to work fine so far. Let me know if you see potential dangers.
>
> >> How do you intend to handle the ambiguous times?
>
> > Thanks a lot Armin. Very insightful.
> > I am not sure what you mean by ambiguous.
>
> I mean that for example 11/6/2011, 01:30 AM (local time) occurs twice.
>
>
>
> > Let me clarify what i am doing, so will be clearer wheter i still
> > will have problems.
>
> > Take and InitialDate. an EDT (est time) date.
> > Starting form that InitialDate i generate a sequence of (date, price)
>
> > The sequence is pretty tight, being the date spaced a few
> > milliseconds.
>
> > The sequence (al est times) run up to another date as to cover N days.
>
> > InitialDate ---------------- *InitialDate +N days
>
> > I use this series for various simulation.
>
> > Now while i am plotting this series (x = time y=price) i also
> > bother, tick by tick, showing what would be the time in LOCAL
> > timezone.
>
> > So i noticed that for some special selection of InitialDate and N i
> > found this error.
> > Now, to correct, i am thinking just to skip (in the loop) the invalid
> > times.
>
> Where does InitialDate come from? Do you verify that it's a valid
> and unambiguous time?
> I would first convert the initial DateTime to UTC. From there
> you can compute the UTC time at every x-position, and from every
> UTC time, you can always and unambiguously compute the local time.
>
> --
> Armin

Thanks Armin. I see.

If the local time appers 2 times it would not hurt. What hurts and is
a big problem is if the EDT time duplicates.
This is because for processing i am actually using the EDT time. While
LOCAL time is meant for illustration purposes only (just display).

Do you think i will still run into troubles?

-Pam

i am trying running this, to verify:
it seems to get through ...


Private Sub Button1_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles Button1.Click


Dim d As New Date(2011, 3, 1)
Dim PreviousEDTDate As Date


Do

Dim NewDate = d.AddDays(1)

If Not TimeZoneInfo_EDT.IsInvalidTime(NewDate) Then

Dim NewDate_EDT As Date =
TimeZoneInfo.ConvertTime(NewDate, TimeZoneInfo_EDT,
TimeZoneInfo_LOCAL)

If NewDate_EDT < PreviousEDTDate Then
MsgBox("Time EDT backed up " & d & " -> " &
NewDate)
End If

If NewDate < d Then
MsgBox("Time backed up " & d & " -> " & NewDate)
End If

d = NewDate
PreviousEDTDate = NewDate

End If

If d > DateTime.MaxValue.AddMonths(-1) Then Exit Do

Loop

MsgBox("Done")

End Sub