by Michael S. Kaplan, published on 2007/08/21 02:30 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/08/20/4489662.aspx
(Intentionally posted at the half hour mark. Subtle, huh?)
Jason's question of the group of people:
Hello All,
I tried using the Following Code which uses new Date ( ) in JScript:
<%
var d = new Date();
Response.Write(d);
/* d prints the local time as Tue Aug 14 21:55:46 UTC+5 2007 The machine
is in IST TimeZone which is UTC+0530 ..But UTC+5 is returned */
var e = new Date(d); // I try to use new Date () again and pass the value d whic was used earlierResponse.Write("<BR>");
Response.Write(e);
/* because UTC+5 is the Time Offset , e prints Tue Aug 14 22:25:58 UTC+5 2007 (30 minutes more
than the system's local time Pls see the pink text highlighted where 30 minutes difference is seen)*/
%>
When I try using New Date () for the first Time, I get the Time with UTC+5.Teh local Time of my machine which is set to IST which is 5.30 hours ahead of UTC. So I should get UTC+530 and not UTC+5.When I try to use new Date again, I get 30 minutes difference compared to my Local Time.
When I try to change my Local Time setting to UTC+9 or UTC+10 or UTC+1 ...... or any natural number (i.e. UTC+1, UTC+2....UTC+12...), I don’t get this error since the value appended is already a whole number. When I try to set Time Zones involving Fractions like( UTC+530 ,UTC+430,UTC+330 ......), I get the UTC offset truncated to (UTC+5,UTC+4,UTC+3...). This undesired output format of Date gives lots of Errors in Storing Time.
Kindly let me know any pointers on this Issue. Any links that can help will be highly appreciated. Thanks in advance.
It turns out that this is actually a bug:
This is a bug in the Jscript .NET implementation, which assumes the timezone offset to be in multiples of hours.
The Jscript engine used by IE (and other hosts in Windows) do not have this bug.
Given that all of the following time zones have offsets that are not on the hour (this is the XP latest list):
A rounding problem? Storing the value in an int? Who can say for sure? It does make one miss good old JScript just a little bit....
Yet another example of how easy it is to have bugs when the test cases don't cover all of the different time zones. :-(
This post brought to you by ༃ (U+0f03, a.k.a. TIBETAN MAL GTER YIG MGO -UM GTER TSHEG MA)
# Bradley on 21 Aug 2007 10:50 AM:
Looks like that list might be missing at least one time zone: Chatham Standard Time (GMT +12:45)
# Michael S. Kaplan on 21 Aug 2007 4:51 PM:
That would be Windows; I used their list, and Chathm is not on it....
# Chuck on 21 Aug 2007 9:46 PM:
And Venezuela will be joining that club next year:
# Zooba on 23 Aug 2007 9:24 AM:
Why is Australian CST listed twice?
AUS Central Standard Time (GMT +09:30)
Cen. Australia Standard Time (GMT +09:30)
The only thing I can think of is the daylight savings settings are different between South Australia and the Northern Territory, both of which use CST.
Michael S. Kaplan on 14 Sep 2007 9:36 AM:
It could also be the desire to list different cities?
referenced by