Further:
> (TimeZoneInfo:ConvertTimeFromUtc (DateTime. 2008 12 31 13 15 0)
wstTimezone)
31/12/2008 10:15:00 PM
> (TimeZoneInfo:ConvertTimeFromUtc (DateTime. 2008 12 31 14 15 0)
wstTimezone)
31/12/2008 11:15:00 PM
> (TimeZoneInfo:ConvertTimeFromUtc (DateTime. 2008 12 31 15 15 0)
wstTimezone)
1/1/2009 12:15:00 AM
> (TimeZoneInfo:ConvertTimeFromUtc (DateTime. 2008 12 31 16 15 0)
wstTimezone)
1/1/2009 12:15:00 AM
> (TimeZoneInfo:ConvertTimeFromUtc (DateTime. 2008 12 31 17 15 0)
wstTimezone)
1/1/2009 1:15:00 AM
> (TimeZoneInfo:ConvertTimeFromUtc (DateTime. 2008 12 31 18 15 0)
wstTimezone)
1/1/2009 2:15:00 AM
But
> (wstTimezone.IsAmbiguousTime (DateTime. 2009 1 1 12 15 0))
False
> (wstTimezone.IsAmbiguousTime (DateTime. 2008 12 31 15 15 0))
False
> (wstTimezone.IsAmbiguousTime (DateTime. 2008 12 31 16 15 0))
False
>
(I didn't look up the documentation to confirm whether IsAmbiguousTime
should work with Utc or Local, but neither are showing true, and yet 1/1/09
12:15 AM local is ambiguous as above.)
The UTC -> Local -> UTC round trip is wrong by an hour between 31/12/08 5
PM and 11:59:59 PM (UTC), with the two hours before that generating times
(Local 1/1/09 Midnight to 1AM twice) that are "Invalid" for return to UTC.
So as well as not existing between 1/1/09 Midnight to 1AM, WA was out of
phase by an hour until Midnight UTC!
On 8 November 2012 12:56, Mark Hurd <markeh...@gmail.com> wrote:
> In this case you've found an hour where WA didn't exist according to
> Microsoft's TimeZone data:
>
> In DotLisp, with wadate as your date and wstTimezone as you've retrieved
> it:
> > (wstTimezone.GetUtcOffset (.AddMinutes wadate 60))
> 09:00:00
> > (wstTimezone.GetUtcOffset (.AddMinutes wadate -1))
> 09:00:00
> > (TimeZoneInfo:ConvertTimeToUtc (.AddMinutes wadate -1)wstTimezone)
> 31/12/2008 2:59:00 PM
> > (TimeZoneInfo:ConvertTimeToUtc (.AddMinutes wadate 60)wstTimezone)
> 31/12/2008 4:00:00 PM
> >
>
> All the local times in between are invalid.
>
> Drop a note at Connect.
>
> --
> Regards,
> Mark Hurd, B.Sc.(Ma.)(Hons.)
>
>
> On 8 November 2012 10:44, Wallace Turner <wallacetur...@gmail.com> wrote:
>
>> This question is similar to [this][1] stackoverflow question insofar as
>> the Exception thrown is clear and explicit:
>>
>> I'm converting the 1st Jan 2009 (perth time) to UTC and getting
>> "*System.ArgumentException:
>> The supplied DateTime represents an invalid time*"
>>
>> [TestMethod]public void TestMethod1(){
>> var date = DateTime.Parse("1-Jan-2009 00:00");
>> var wstTimezone = TimeZoneInfo.FindSystemTimeZoneById("W. Australia
>> Standard Time");
>> Trace.WriteLine(wstTimezone.IsInvalidTime(date));//is invalid
>> Trace.WriteLine(TimeZoneInfo.ConvertTime(date, wstTimezone,
>> TimeZoneInfo.FindSystemTimeZoneById("UTC")));//throw Exception}
>>
>>
>>
>>
>> 1) I'm more curious than concerned - *Can anyone out here in the west
>> recall why this time might be invalid?* One hour either side of this
>> works ok; I can't recall daylight savings moving/changing during this
>> period.
>>
>> 2) In general, how are people handling cases like this? For example, if
>> you have a user who wants to select all the foos from 1st Jan 2009 onwards
>> then you would naturally get the start time in the users timezone
>> (1-Jan-2009 00:00) and convert to UTC - this is especially problematic if
>> you only allow the user to select the start and end date (no times) which
>> means you'd have to ask the user to select a different date completely
>> because 'midnight didnt exist in your timezone on the selected date'
>>
>> Hope I'm making sense
>>
>> Wal
>>
>>
>> [1]:
>> http://stackoverflow.com/questions/2416439/exception-calling-when-timezoneinfo-converttimetoutc-for-certain-datetime-values
>>
>
>
--
Regards,
Mark Hurd, B.Sc.(Ma.)(Hons.)
