Daylight Savings leap bugs?
Adam Peller
daylight savings rules in certain timezones. The first appears to be
specific to FF and a host platform on the Unix epoch date:
https://bugzilla.mozilla.org/show_bug.cgi?id=487897
>>> new Date(1970,0,1,0,0,0,0)
Thu Jan 01 1970 01:00:00 GMT+0100 (IST)
>>> new Date(1970,0,1,0,0,0,0).getHours()
1
// you'd expect 0
which is unfortunate, since time=0 is often used in Date calculations.
The second problem appears in most browsers I've tested. In essence,
construct a Date object for the day where summer time begins in
Argentina, and it throws you back an hour to the previous day:
http://bugs.dojotoolkit.org/ticket/9366
>>> new Date(2009,9,18)
Sat Oct 17 2009 23:00:00 GMT-0300 (ART)
Because the date shift occurs at midnight, perhaps there really is no
'midnight' that day? I'm wondering why it throws me backwards instead
of forwards, unless this is a bug in some algorithm which assumes
northern hemisphere rules? Using Date as a container for month and
date, especially in local time, clearly has its problems, but I think
it's generally expected behavior that the date remain constant. Is
this a bug in JS? In the host OS? Or does this actually make sense to
anyone? Generally speaking, are there rules for what should happen
during a dst leap, particularly on the boundary?
-Adam
Thomas 'PointedEars' Lahn
> I've encountered a couple of surprising behaviors in Date relative to
> daylight savings rules in certain timezones. The first appears to be
> specific to FF and a host platform on the Unix epoch date:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=487897
You can bet that will become INVALID, WONTFIX. There is no bug as you will
see shortly.
>>>> new Date(1970,0,1,0,0,0,0)
> Thu Jan 01 1970 01:00:00 GMT+0100 (IST)
>>>> new Date(1970,0,1,0,0,0,0).getHours()
> 1
> // you'd expect 0
You would _not_. The hour of the date value is clearly 1 (you said so
yourself!); Epoch is defined as 1970-01-01 (CE) 00:00 _UTC_ (which for all
intents and purposes is GMT+0000), and so 1970-01-01 01:00:00 GMT+0100.
> which is unfortunate, since time=0 is often used in Date calculations.
new Date(0)
will get you Epoch a bit more efficient. While it will be a date value with
a time zone offset according to the client (there is no bug), DST does not
enter into it since DST did not and does not start or end anywhere near New
Year's Day in any country.
> The second problem appears in most browsers I've tested. In essence,
> construct a Date object for the day where summer time begins in
> Argentina, and it throws you back an hour to the previous day:
>
> http://bugs.dojotoolkit.org/ticket/9366
>
>>>> new Date(2009,9,18)
> Sat Oct 17 2009 23:00:00 GMT-0300 (ART)
That's another reason why one wouldn't rely on the client time for a Web
application.
> Because the date shift occurs at midnight, perhaps there really is no
> 'midnight' that day?
There is, of course. 01:00 GMT-0200 is 00:00 GMT-03:00.
> I'm wondering why it throws me backwards instead of forwards,
Because DST *ends* later that day and thus clocks are to be set an hour
backwards then. Without having checked the Specification, I presume that
because there is no way of knowing if you mean a value before of after the
switching, it picks the most probable time zone for that day (2000-08-18)
and your locale which is GMT-0200 (after the switching).
Ceterum censeo DST esse delendam.
PointedEars
Adam Peller
wrote:
> >>>> new Date(1970,0,1,0,0,0,0)
> > Thu Jan 01 1970 01:00:00 GMT+0100 (IST)
> >>>> new Date(1970,0,1,0,0,0,0).getHours()
> > 1
> > // you'd expect 0
>
> You would _not_. The hour of the date value is clearly 1 (you said so
> yourself!); Epoch is defined as 1970-01-01 (CE) 00:00 _UTC_ (which for all
> intents and purposes is GMT+0000), and so 1970-01-01 01:00:00 GMT+0100.
Whoa, hold on. I'm not dealing with time=0 or UTC in my example
(sorry if I implied otherwise). If I had done something like new Date
(0).getHours() in that time zone or used the UTC function, I
definitely would expect to get a 1, but I'm _not_. I'm constructing
midnight, Jan 1, 1970 in local time, allegedly one hour off from UTC
at that point in time, and asking for the hours back in local time.
That seems to return "0" when I run the test anywhere but IST on FF/
non-Win. Unless this is the same problem of a DST leap occurring
exactly at that moment (as you say, very unlikely) I'd expect getHours
to return me the hours in local time, i.e. midnight. Granted, this is
not the exact epoch, it's the same day as the epoch, and the code
probably should be dealing in UTC, but it's not. Still not a browser
bug? Perhaps we can blame it on the host?
> new Date(0)
>
> will get you Epoch a bit more efficient.
Agreed. That's the Epoch. What I had in my example was not, and that
itself is a bug.
...
> > Because the date shift occurs at midnight, perhaps there really is no
> > 'midnight' that day?
>
> There is, of course. 01:00 GMT-0200 is 00:00 GMT-03:00.
>
> > I'm wondering why it throws me backwards instead of forwards,
>
> Because DST *ends* later that day and thus clocks are to be set an hour
> backwards then.
Careful, we're talking about the southern hemisphere. October is when
they leap forward. I guess what I meant to say is that there's no
representation of midnight in that timezone using the JS Date Object
in local time. You could certainly represent the value unambiguously
in UTC, which is what I think the spec suggests... anything else is up
to magical daylight savings algorithms which vary over time (I believe
ES5 is corrected to point this out) All that said, I still can't
understand why it would bump me back to 23h.
-Adam
Doug Miller
In article
<54429e6d-86a8-48ff...@o14g2000vbo.googlegroups.com>, Adam
Peller <pel...@gmail.com> wrote:
>Because the date shift occurs at midnight
No, it doesn't. It occurs at 0200 local civil time.
http://www.nist.gov/public_affairs/faqs/qdaylite.htm
Adam Peller
> No, it doesn't. It occurs at 0200 local civil time.http://www.nist.gov/public_affairs/faqs/qdaylite.htm
Ummm... that's in the U.S. Sorry, re-reading my post I realized I
forgot to call out the fact that this bug report indicates problems in
Argentina GMT-0300 (ART)
David Mark
[snip]
>
> The second problem appears in most browsers I've tested. In essence,
> construct a Date object for the day where summer time begins in
> Argentina, and it throws you back an hour to the previous day:
>
> http://bugs.dojotoolkit.org/ticket/9366
>
> >>> new Date(2009,9,18)
>
> Sat Oct 17 2009 23:00:00 GMT-0300 (ART)
>
When I first read about this issue, it seemed like this was something
that could be avoided (at least for this widget.) Why does the date
selection need to be converted to a JS Date? I would store/send the
selection as three numbers.
Is it to figure offsets or range lengths? ISTM such calculations will
not be a problem. See Stockton's examples. I'm sure if there are
issues with this they have been addressed there.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>>>>>> new Date(1970,0,1,0,0,0,0)
>>> Thu Jan 01 1970 01:00:00 GMT+0100 (IST)
>>>>>> new Date(1970,0,1,0,0,0,0).getHours()
>>> 1
>>> // you'd expect 0
>> You would _not_. The hour of the date value is clearly 1 (you said so
>> yourself!); Epoch is defined as 1970-01-01 (CE) 00:00 _UTC_ (which for all
>> intents and purposes is GMT+0000), and so 1970-01-01 01:00:00 GMT+0100.
>
> midnight, Jan 1, 1970 in local time, allegedly one hour off from UTC
> at that point in time, and asking for the hours back in local time.
Sorry, my bad. I re-read your posting several times and still confused the
arguments. (Apparently the need for vacation is urgent.)
> That seems to return "0" when I run the test anywhere but IST on FF/
> non-Win. [...]
ACK
> Granted, this is not the exact epoch, it's the same day as the epoch,
> and the code probably should be dealing in UTC, but it's not. Still
> not a browser bug?
I can't be sure. If the behavior does occur neither in another UA on the
same platform nor in Firefox on another platform, same local time zone
(incl. DST conditions) provided, it probably is a bug.
> Perhaps we can blame it on the host?
Why, we can always blame it on the host :)
>>> Because the date shift occurs at midnight, perhaps there really is no
>>> 'midnight' that day?
>> There is, of course. 01:00 GMT-0200 is 00:00 GMT-03:00.
>>
>>> I'm wondering why it throws me backwards instead of forwards,
>> Because DST *ends* later that day and thus clocks are to be set an hour
>> backwards then.
>
> Careful, we're talking about the southern hemisphere. October is when
> they leap forward.
Of course. But a time zone naturally spans both the northern and the
southern hemisphere, and DST ist much more common on the northern one.
Furthermore, JavaScript was created, and ECMAScript was specified, by people
from the northern hemisphere, so that might have provided additional reason
for a bias.
ART (Argentina Time) is also special because in Argentina there is no fixed
annual schedule for DST, so that may be another explanation as to why you
are set backwards there.
<http://en.wikipedia.org/wiki/Daylight_saving_time_around_the_world>
> [...] All that said, I still can't understand why it would bump me back
> to 23h.
Well, it isn't really "back", is it? The time value would be the same, only
hour and time zone differ from expectations. You can (and apparently
should) use Date.prototype.getTimezoneOffset() to consider the difference in
your computations.
PointedEars
Doug Miller
>On Jun 3, 12:16=A0pm, spamb...@milmac.com (Doug Miller) wrote:
>> No, it doesn't. It occurs at 0200 local civil time.http://www.nist.gov/pu=
>blic_affairs/faqs/qdaylite.htm
>
>Ummm... that's in the U.S. Sorry, re-reading my post I realized I
>forgot to call out the fact that this bug report indicates problems in
>Argentina GMT-0300 (ART)
Indeed you did neglect to specify that. And since you're posting from an IP
address in the U.S. ...
Dr J R Stockton
3 Jun 2009 17:00:35, Thomas 'PointedEars' Lahn <Point...@web.de>
posted:
>
> new Date(0)
>
>will get you Epoch a bit more efficient. While it will be a date value with
>a time zone offset according to the client (there is no bug),
No. The Date Object is an IEEE Double, with Methods. It contains no
offset.
"Time zone offset" is bad terminology, originated by an ill-educated
nerd. Where there is Summer Time, the Offset changes seasonally. But
the Time Zone does not change seasonally; it is only changed (like the
status of Schleswig-Holstein) politically. Method getTimeZoneOffset
should be replaced by getTimeOffset.
> DST does not
>enter into it since DST did not and does not start or end anywhere near New
>Year's Day in any country.
A true Time Zone change, however, could occur after New Year's Eve - boy
most politicians would prefer to do it when the people are more likely
to be, on the whole, sober and asleep.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk IE7 FF3 Op9 Sf3
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Dr J R Stockton
4g2000vbo.googlegroups.com>, Wed, 3 Jun 2009 06:54:21, Adam Peller
<pel...@gmail.com> posted:
>I've encountered a couple of surprising behaviors in Date relative to
>daylight savings rules in certain timezones. The first appears to be
>specific to FF and a host platform on the Unix epoch date:
Summer Time rules are not governed by time zones. All EU has the same
rules (assuming UTC=GMT), but covers 3 zones. Russia has one set of
rules, but is in about 11 time zones. Perth & Beijing are in the same
zone, but have different rules. Chile, Venezuela, and Labrador appear
to be in the same zone, but have different rules.
You need to say exactly what the machine and OS are, and to what
location they are set. Unless you write the full story with complete
unambiguity, one cannot be certain what you mean.
>https://bugzilla.mozilla.org/show_bug.cgi?id=487897
>
>>>> new Date(1970,0,1,0,0,0,0)
>Thu Jan 01 1970 01:00:00 GMT+0100 (IST)
>>>> new Date(1970,0,1,0,0,0,0).getHours()
>1
>// you'd expect 0
>
>which is unfortunate, since time=0 is often used in Date calculations.
IST has at least three possible meanings in this context.
If IST is supposed to represent Irish Standard Time, you should be aware
that the British Isles, normally with clocks set to GMT in winter, had
them advanced by an hour for three years around that time. The UK did
this by extending the duration of British Summer Time (BST and calling
the time British Standard Time (BST).
The Irish, presumably noting that Summer is longer than Winter, did it
differently. While the Republic of Ireland's clocks were kept in
agreement with those of the UK of GB & NI, the RoI apparently advanced
their Standard Time by one hour and, instead of putting them forward for
the Summer, put them back for the Winter. It seems unclear what they
did at the end of the "extended-summer" period, except that their clocks
continued to agree with UK ones.
Now, in the EU, we all must change the clock at 01:00 UTC (or GMT) on
the last Sundays of March and October; but I don't recall whether we are
permitted to choose between putting them forward for the Summer or back
for the winter.
The "TZ" notation could handle Winter Time by swapping the dates and
using a negative shift; but the detailed grammar may not allow the
nece3ssary minus sign.
>The second problem appears in most browsers I've tested. In essence,
>construct a Date object for the day where summer time begins in
>Argentina, and it throws you back an hour to the previous day:
Wikipedia says that only some of Argentina has Summer Time.
>http://bugs.dojotoolkit.org/ticket/9366
>
>>>> new Date(2009,9,18)
>Sat Oct 17 2009 23:00:00 GMT-0300 (ART)
>Because the date shift occurs at midnight, perhaps there really is no
>'midnight' that day?
Consult the Azores setting (or Canaries?). Some such place is an hour
behind GMT in Winter (i.e. like New York, but not as bad), and, if
following EU rules, must change its clocks either to or from midnight
local time.
> I'm wondering why it throws me backwards instead
>of forwards, unless this is a bug in some algorithm which assumes
>northern hemisphere rules? Using Date as a container for month and
>date, especially in local time, clearly has its problems,
It is not such. It contains only a count of milliseconds with
1970-01-01 00:00:00 UTC being the Zero Second. There are methods to
calculate, for example, the Month. Timing may be able to demonstrate
that getMonth is slower than getTime.
Reports of offset are obtained by consulting, or by having consulted at
browser load (or ?), the OS for the CURRENT Summer Time Rules for the
set location - OR by asking the OS to convert. There can be no problem
with Windows before Vista, as it only knows one set of rules per
location. AIUI, Vista knows two sets, to handle the US rule change of
2007-03-01 unspecified time; AIUI, a UNIX system knows all. Therefore,
Vista & Unix potentially can commit the sin of using non-current rules
nor non-current dates.
> but I think
>it's generally expected behavior that the date remain constant. Is
>this a bug in JS? In the host OS? Or does this actually make sense to
>anyone? Generally speaking, are there rules for what should happen
>during a dst leap, particularly on the boundary?
There is ambiguity in the Real World Rules as to whether, for example,
on the last Sunday of March the ideal UK clock will show 01:00 for an
infinitesimal time before changing to 02:00, or whether at the end of
00:59 it will go straight to 02:00. There will also be doubt about what
implementations do.
Example : DOS has 0x1800B0 ticks per day, starting at 0. The code
indicates, IIRC, that the clock actually is set to 0x1800B0, but there
is then a comparison which will set it to 0x0 and set the Tomorrow bit.
But the nature of DOS makes that sequence apparently un-interruptible,
so that user code cannot see 0c1800B0. BTW, in code I saw, the
comparison is for equality; so if one sets the value to 0x1800B0 by a
sort of "Poke" it will continue to rise, TIME shows hours>23, and
eventually confusion sets in.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
Dr J R Stockton
4g2000vbo.googlegroups.com>, Wed, 3 Jun 2009 09:08:25, Adam Peller
<pel...@gmail.com> posted:
>
>Careful, we're talking about the southern hemisphere. October is when
>they leap forward. I guess what I meant to say is that there's no
>representation of midnight in that timezone using the JS Date Object
>in local time. You could certainly represent the value unambiguously
>in UTC, which is what I think the spec suggests... anything else is up
>to magical daylight savings algorithms which vary over time (I believe
>ES5 is corrected to point this out) All that said, I still can't
>understand why it would bump me back to 23h.
Be aware that the Date Object contains only an IEEE Double of
milliseconds UTC from Epoch. A Double represent any millisecond within
2^53 of Epoch (and many others), but a standard-compliant Date Object
can only hold a value not greater in absolute value than 86400000E8,
being 10^8 days. (At least one major browser does not comply - Safari 3
fails Test 09 on my js-datex.htm.)
There are some times that could be plausibly written that JavaScript
will not output, corresponding to what the local clock jumps over in
Spring. It can read such strings.
The Standard does not define sensible conversions between Date & String;
so one cannot expect it to cover difficult cases.
My js-date2.htm can show when the JavaScript clock changes occur for the
current location. Windows 98 got that wrong for the UK.
Opera, up to 9.61 but not 9.64, in Windows XP, did strange things with
UK Summer Time outside 0 <= time_t < 2^31 seconds, which casts doubt
on its internal arrangements.
--
(c) John Stockton, near London. *@merlyn.demon.co.uk/?.?.Stockton@physics.org
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Correct <= 4-line sig. separator as above, a line precisely "-- " (SoRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SoRFC1036)
Adam Peller
> When I first read about this issue, it seemed like this was something
> that could be avoided (at least for this widget.) Why does the date
> selection need to be converted to a JS Date? I would store/send the
> selection as three numbers.
We're getting a bit off topic but, well, it's nice to have some
abstraction for a date or date+time when writing library routines.
JavaScript has one, so I think the instinct was to use what's
provided. Dates, unlike an array, are self-descriptive and are likely
to be used in other Date calculations, by this library and other
code. Sure, Dojo could have used a hash object or created its own
Date object, but why should one need to do that? (One reason would be
that Date objects are expensive, but we're talking about a single
instance here)
Over the wire, Dojo best practice is to use ISO formatted dates and
times, exclusively. Programmatically, Date objects seem more
intuitive to deal with, at least when they do what you expect them
to :)
> Is it to figure offsets or range lengths? ISTM such calculations will
> not be a problem. See Stockton's examples. I'm sure if there are
> issues with this they have been addressed there.
In most examples in Dojo, Date objects are used for a single point in
time or to represent a date where the time portion is ignored, in
which case a Date object really isn't precise (the old date vs
datetime problem) Still, it seems perfectly reasonable to me to use
Date objects to encapsulate either one.
-Adam
Adam Peller
> >Ummm... that's in the U.S. Sorry, re-reading my post I realized I
> >forgot to call out the fact that this bug report indicates problems in
> >Argentina GMT-0300 (ART)
>
> Indeed you did neglect to specify that. And since you're posting from an IP
> address in the U.S. ...
So that's part of the problem. Arrogant Americans, like myself, need
to write code that works everywhere. :-)
David Mark
> On Jun 3, 2:20 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > When I first read about this issue, it seemed like this was something
> > that could be avoided (at least for this widget.) Why does the date
> > selection need to be converted to a JS Date? I would store/send the
> > selection as three numbers.
>
> We're getting a bit off topic but, well, it's nice to have some
> abstraction for a date or date+time when writing library routines.
Of course. I'm just saying we can store it as numbers and then
convert it to Date objects when and as needed.
> JavaScript has one, so I think the instinct was to use what's
> provided. Dates, unlike an array, are self-descriptive and are likely
> to be used in other Date calculations, by this library and other
> code.
Sure. For instance the value property of the widget (I think that was
the name) is a Date, set each time the selection changes. AIUI the
selection is currently stored internally as a Date, which looks like
something we should avoid.
> Sure, Dojo could have used a hash object or created its own
> Date object, but why should one need to do that? (One reason would be
> that Date objects are expensive, but we're talking about a single
> instance here)
I haven't dug too far into the date handling, but I thought Dojo had
its own date-like object.
>
> Over the wire, Dojo best practice is to use ISO formatted dates and
> times, exclusively. Programmatically, Date objects seem more
> intuitive to deal with, at least when they do what you expect them
> to :)
Yes. If this widget - for example - had a getDayOfMonth method, it
would be hard-pressed to extract it from a Date and match the user's
selection (at least in Argentina.) :)
>
> > Is it to figure offsets or range lengths? ISTM such calculations will
> > not be a problem. See Stockton's examples. I'm sure if there are
> > issues with this they have been addressed there.
>
> In most examples in Dojo, Date objects are used for a single point in
> time or to represent a date where the time portion is ignored, in
> which case a Date object really isn't precise (the old date vs
> datetime problem) Still, it seems perfectly reasonable to me to use
> Date objects to encapsulate either one.
I think the former always and the latter sometimes. I think we are
running into a situation with this widget that will call for another
strategy. I'll have to look again at what exactly is broken. The
test page fills in a text input with the proper time, though some
times will not be exactly what you expect due to conversion issues.
As long as that doesn't break the widget, it isn't a problem. But
there was the other issue of typing the date and that was completely
broken for this one date in Argentina. Did you figure out what was
going wrong there?
Adam Peller
> I haven't dug too far into the date handling, but I thought Dojo had
> its own date-like object.
Nope. Dojo tries to stay out of the business of doing what core
Javascript already does. We do have a dojo.date package with utility
methods, most of which take Date as an argument, also dojo.date.stamp
for ISO support and dojo.date.locale for CLDR formatting and parsing
for user interaction. Most recently, we've accepted some experimental
packages which create duck-typed objects like Dates to support non-
Gregorian calendars.
> I think the former always and the latter sometimes. I think we are
> running into a situation with this widget that will call for another
> strategy. I'll have to look again at what exactly is broken. The
> test page fills in a text input with the proper time, though some
> times will not be exactly what you expect due to conversion issues.
> As long as that doesn't break the widget, it isn't a problem. But
> there was the other issue of typing the date and that was completely
> broken for this one date in Argentina. Did you figure out what was
> going wrong there?
Although I do not understand why JS chooses to repeat the 23rd hour in
this particular case, I'm willing to accept that it's just some 'host
thing' (it occurs on more than one platform, though I have not done a
conclusive test on all platforms I have available) For now, in Dojo
I've simply put in a one hour adjustment to add an hour when there is
such an underflow. That assumes, among other things a one hour
underflow results from such a shift. It applies not just to this
widget, but to the Date parsing logic in dojo.date.locale. You can
examine the changesets in trac in the ticket on my original note.
I post here because I was concerned about the Javascript case, in
general, not the Dojo bug. I figure this is the type of thing someone
is bound to trip over, and most of the time they won't know it, as the
test matrix for running your code against other timezones and daylight
savings rules is large and impossible to automate, if such test cases
were even considered.
David Mark
> On Jun 3, 8:54 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
[snip]
>
> > I think the former always and the latter sometimes. I think we are
> > running into a situation with this widget that will call for another
> > strategy. I'll have to look again at what exactly is broken. The
> > test page fills in a text input with the proper time, though some
> > times will not be exactly what you expect due to conversion issues.
> > As long as that doesn't break the widget, it isn't a problem. But
> > there was the other issue of typing the date and that was completely
> > broken for this one date in Argentina. Did you figure out what was
> > going wrong there?
>
> Although I do not understand why JS chooses to repeat the 23rd hour in
> this particular case, I'm willing to accept that it's just some 'host
> thing' (it occurs on more than one platform, though I have not done a
> conclusive test on all platforms I have available) For now, in Dojo
> I've simply put in a one hour adjustment to add an hour when there is
> such an underflow. That assumes, among other things a one hour
> underflow results from such a shift. It applies not just to this
> widget, but to the Date parsing logic in dojo.date.locale. You can
> examine the changesets in trac in the ticket on my original note.
>
> I post here because I was concerned about the Javascript case, in
> general, not the Dojo bug. I figure this is the type of thing someone
> is bound to trip over, and most of the time they won't know it, as the
> test matrix for running your code against other timezones and daylight
> savings rules is large and impossible to automate, if such test cases
> were even considered.
I know. I just think the one-hour underflow assumption is incorrect.
Seems like the time zone offset must be considered. I'll look at the
patch tomorrow. I think I understand what PE was saying about this.
Perhaps he will elaborate in the meantime.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn posted:
>> new Date(0)
>>
>> will get you Epoch a bit more efficient. While it will be a date value with
>> a time zone offset according to the client (there is no bug),
>
> No. The Date Object is an IEEE Double, with Methods. It contains no
> offset.
However, I get
// Thu Jan 01 1970 01:00:00 GMT+0100 (CET)
new Date(0)
// -60
new Date(0).getTimezoneOffset()
in Firefox 3.0.9/Linux. How do you explain that?
> "Time zone offset" is bad terminology, originated by an ill-educated
> nerd.
A matter of opinion, and I don't agree.
<https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Date/getTimezoneOffset>
> Where there is Summer Time, the Offset changes seasonally. But
> the Time Zone does not change seasonally; it is only changed (like the
> status of Schleswig-Holstein) politically. Method getTimeZoneOffset
> should be replaced by getTimeOffset.
And yet that offset is directly related to the locale's time zone.
>> DST does not enter into it since DST did not and does not start or end
>> anywhere near New Year's Day in any country.
>
> A true Time Zone change, however, could occur after New Year's Eve - boy
> most politicians would prefer to do it when the people are more likely
> to be, on the whole, sober and asleep.
ACK :)
PointedEars
Evertjan.
> However, I get
>
> // Thu Jan 01 1970 01:00:00 GMT+0100 (CET)
> new Date(0)
>
> // -60
> new Date(0).getTimezoneOffset()
Nothing wrong with that, Thomas, all browsers should and do that.
getTimezoneOffset() is defined as
the GMT minutes offset as seen from the actual local time.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Dr J R Stockton
0g2000vbg.googlegroups.com>, Wed, 3 Jun 2009 11:20:48, David Mark
<dmark....@gmail.com> posted:
I knew that removing 'Manipulating times, dates and the lastModified
date and time in javascript:- <http://www.merlyn.demon.co.uk/js-
dates.htm>' from "3.2 What online resources are available?" between FAQ
8.1 & FAQ 9.91 was unhelpful. Note that the wording was crafted to be
found by most reasonable searchers.
As an illustration of the need for exactness in expression : My WinXP
has no "Argentina" setting. It has one for "Buenos Aires" and a number
of others for places nearby that are probably not in Argentina. It also
has "Old" and "New" for Mexico City - but what if the Mexicans make a
second change? AIUI, they did not follow the US change on 2007-03-01.
If the Argies do change at local midnight, Sat/Sun then their Spring
change MUST render all local times BETWEEN 00:00:00 and 01:00:00 non-
existent, PLUS exactly one of those two stated times.
Obvious tests are to try setting 23:00 00:00 01:00 02:00, in each case
exact and a minute off either way; and to do likewise for Autumn.
<http://www.timeanddate.com/time/dst2009.html> - this year, Argentina
changes on Sunday, October 18 & Sunday, March 15 except that parts do
not. And <http://www.timeanddate.com/worldclock/clockchange.html?n=51>
gives details : in Autumn, Saturday seconds 23:00:00 to 23:59:59 are
duplicated; in Spring, Sunday seconds 00:00:00 to 00:23:59 are omitted.
One should note that it is (generally) only necessary to work in Local
Time if new Date() is used other than for timing intervals.
Calendar work can be done with the UTC methods, for anywhere in the
world. Example : Book a hotel room in Podunk, wherever that may be, for
the weekend of the second Sunday in March, Friday 9pm to Sunday 9pm.
You will probably not be given a discount of ~2% for not being there on
Sunday between 2am & 3am. Stay the same times on the weekend of the
last Sunday of October, and you will not expect to be charged an extra
2% for occupying it twice between 1am & 2am.
Using UTC throughout requires a little more typing[*], is more reliable,
and quicker.
Setting a date/time in the clock jump interval, including both ends, is
imprudent. One may know what should happen; but there is no need to
rely on all systems agreeing. Work needing dates but not times can be
more safely done by setting noon rather than midnight (and rounding
differences) - except, maybe, near and on the wrong side of the Date
Line.
[*] Except with <URL:http://www.merlyn.demon.co.uk/js-dobj2.htm>.
Dr J R Stockton
4 Jun 2009 12:16:55, Thomas 'PointedEars' Lahn <Point...@web.de>
posted:
>Dr J R Stockton wrote:
>> Thomas 'PointedEars' Lahn posted:
>>> new Date(0)
>>>
>>> will get you Epoch a bit more efficient. While it will be a date value with
>>> a time zone offset according to the client (there is no bug),
>>
>> No. The Date Object is an IEEE Double, with Methods. It contains no
>> offset.
>
>However, I get
>
> // Thu Jan 01 1970 01:00:00 GMT+0100 (CET)
> new Date(0)
>
> // -60
> new Date(0).getTimezoneOffset()
>
>in Firefox 3.0.9/Linux. How do you explain that?
It is because you are in, or at least have told your machine that it is
in, the time zone one to the East of here, and that similarly your
settings have no Summer Time for January 1st.
When one calls a Method of Date that needs to know the difference
between Local Time and GMT for the (IEEE Double) value of the Object, it
consults the Time Rules for the location, obtained from the operating
system either on demand or on browser start-up or elsewhen.
You should read ISO/IEC 16262 section 15.9. If a Date Object contained
an Offset field, that would say so. Try reading, too, all sentences of
16262 that contain the string "zone"/"Zone".
You could try setting your machine to UK. If you get the same results,
your Firefox has a known-possible bug, and uses the then-current rather
than the now-current Rules. That bug cannot be available in Windows
before Vista, could but will not be in Vista and probably 7 (UK Rules
have changed more than once since 1970), and AIUI is possible in all
UNIX-type systems since they allowed for the existence of Summer Time
Rules other than the then-current American ones.
>> "Time zone offset" is bad terminology, originated by an ill-educated
>> nerd.
>
>A matter of opinion, and I don't agree.
>
><https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_
>Objects/Date/getTimezoneOffset>
You should consult dictionaries for the true meanings of words, not
computer specifications. The Washington Conference of 1884 can also be
considered authoritative.
>> Where there is Summer Time, the Offset changes seasonally. But
>> the Time Zone does not change seasonally; it is only changed (like the
>> status of Schleswig-Holstein) politically. Method getTimeZoneOffset
>> should be replaced by getTimeOffset.
>
>And yet that offset is directly related to the locale's time zone.
Only secondarily. It depends on the Time Zone, on whether the place
uses Summer Time and if so whether it is Summer and what the chosen
clock change is.
The offset is an offset of time and should be correspondingly named.
TC39 should know that.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Dr J R Stockton
4g2000vbn.googlegroups.com>, Wed, 3 Jun 2009 15:57:24, Adam Peller
<pel...@gmail.com> posted:
>In most examples in Dojo, Date objects are used for a single point in
>time or to represent a date where the time portion is ignored, in
>which case a Date object really isn't precise (the old date vs
>datetime problem)
That is best done, in JavaScript, by using just the UTC methods and then
having all times-of-day (by default) zero.
Replace new Date(Y, M, D) by new Date(Date.UTC(Y, M, D))
and new Date(String) by new Date(String + " GMT")
and don't use, explicitly or implicitly, Date's toString method.
Alternatively, don't use Date Objects; use a positive Daycount from some
convenient and preferably standard origin, and have routines to convert
between Y M D and daycount and string. See my site.
--
Conrad Lender
> "Time zone offset" is bad terminology, originated by an ill-educated
> nerd. Where there is Summer Time, the Offset changes seasonally.
> But the Time Zone does not change seasonally; it is only changed
> (like the status of Schleswig-Holstein) politically.
I'm not an expert in time zones, but unless I'm mistaken, the time
zone's name changes as well when it passes into summer time (CET -> CEST
in Thomas's case, I believe).
<slightly offtopic>Personally, I think a lot of energy and money could
be saved by abolishing daylight saving time altogether - never mind the
suggested savings from lower heating costs (which have been disputed,
and are actually negative in some climates), given all the effort people
have to spend dealing with shifting time offsets (IT anybody?), I doubt
there'd be any net savings left.</slightly>
BTW, the Schleswig-Holstein quip made me smile :-)
- Conrad
Adam Peller
wrote:
> That is best done, in JavaScript, by using just the UTC methods and then
> having all times-of-day (by default) zero.
>
> Replace new Date(Y, M, D) by new Date(Date.UTC(Y, M, D))
That assumes that all users of Dojo APIs will use getUTC* methods to
pull months, dates, etc from the Date objects. I don't see that
happening. Whatever the case, that's not why I posted here. I was
merely hoping to discuss this in the abstract, and the surprise a user
might have to see this behavior from the Date constructor.
In summary, my understandings are (may or may not have been covered in
this thread)
* During a daylight leap, using the local time constructor which is
incapable of specifying timezones, offsets, or daylight savings rules,
there's an hour on the clock that simply doesn't exist (e.g. midnight
through 12:59am in the location on the date mentioned previously)
* The behavior of the Date constructor, apparently, is unspecified and
left to the host environment, which will choose some arbitrary
replacement, in this case repeating the 23rd hour just prior to
midnight -- yes, the same hour with the same offset from GMT -- is
what I've seen on more than one platform
* This leads to all sorts of surprising behaviors, like setting a
date, then immediately getting the date back and seeing that it
doesn't match what you set. Or, call setHours(0) twice on the date
object, and it will change the date each time. Fun.
I'm not talking about best practices here, just the somewhat
surprising behavior to anyone using Date(y,m,d). Yes, these are all
very good reasons not to use the local Date constructor this way.
David Mark
> On Jun 4, 2:30 pm, Dr J R Stockton <reply0...@merlyn.demon.co.uk>
> wrote:
>
> > That is best done, in JavaScript, by using just the UTC methods and then
> > having all times-of-day (by default) zero.
>
> > Replace new Date(Y, M, D) by new Date(Date.UTC(Y, M, D))
>
> That assumes that all users of Dojo APIs will use getUTC* methods to
> pull months, dates, etc from the Date objects. I don't see that
> happening. Whatever the case, that's not why I posted here. I was
> merely hoping to discuss this in the abstract, and the surprise a user
> might have to see this behavior from the Date constructor.
The biggest surprise would be getting the wrong date from the calendar
widget. The use of the Date constructor to convert a month, day and
year into a time/date that may fall on a different day indicates one
of two things: we must change the internal storage (which is currently
a public property) or we must adjust for underflows as they occur.
The latter is the only possibility at the moment as we must preserve
the current API.
>
> In summary, my understandings are (may or may not have been covered in
> this thread)
>
> * During a daylight leap, using the local time constructor which is
> incapable of specifying timezones, offsets, or daylight savings rules,
> there's an hour on the clock that simply doesn't exist (e.g. midnight
> through 12:59am in the location on the date mentioned previously)
The hour exists, but it is a tricky hour to name. This makes it very
difficult to convert from - for example - a string to a value and back
again without mutation. Depending on the context, such mutations may
or may not require adjustments.
> * The behavior of the Date constructor, apparently, is unspecified and
> left to the host environment, which will choose some arbitrary
> replacement, in this case repeating the 23rd hour just prior to
> midnight -- yes, the same hour with the same offset from GMT -- is
> what I've seen on more than one platform
Yes.
> * This leads to all sorts of surprising behaviors, like setting a
> date, then immediately getting the date back and seeing that it
> doesn't match what you set. Or, call setHours(0) twice on the date
> object, and it will change the date each time. Fun.
All best avoided when possible.
>
> I'm not talking about best practices here, just the somewhat
> surprising behavior to anyone using Date(y,m,d).
It is a surprise the first time (imagine my disbelief the first time
IE threw an exception on a type conversion.) Won't be surprised
again.
> Yes, these are all
> very good reasons not to use the local Date constructor this way.
Absolutely.
Dr J R Stockton
dn...@supernews.com>, Fri, 5 Jun 2009 05:36:37, Conrad Lender
<crle...@yahoo.com> posted:
>On 03/06/09 22:31, Dr J R Stockton wrote:
>> "Time zone offset" is bad terminology, originated by an ill-educated
>> nerd. Where there is Summer Time, the Offset changes seasonally.
>> But the Time Zone does not change seasonally; it is only changed
>> (like the status of Schleswig-Holstein) politically.
>
>I'm not an expert in time zones,
Obviously.
> but unless I'm mistaken, the time
>zone's name changes as well when it passes into summer time (CET -> CEST
>in Thomas's case, I believe).
Time Zones do not change seasonally. Therefore their names cannot
change seasonally.
Nova Scotia names its Time Zone "AT" for "Atlantic Time" - but Chile is
in the same Time Zone, and does not use that name. Both are UTC-4 in
Winter and UTC-3 in Summer, though they disagree as to when those
seasons are.
Often, LCT (Local Civil Time) has two names at one place, one referring
to the time used there in Winter and another to the time used in Summer.
Thomas is (I think) in the Time Zone of N'Djamena, where the time is not
CET but WAT (year-round), and of Windhoek where SAST is (?) used.
Time Zones have numbers (and letters, except that there are too few
letters), not names; the numbers increase Eastwards, and the number used
in an application may be either 0 or 12 for the Zone including the UK.
Castro & Obama live in the same time zone, and their bedside clocks
should agree year-round; but I doubt whether Fidel calls his time
EST/EDT or a direct Spanish version thereof.
One does not expect the commoner sort of US computing nerd (and it is
they who tend to name things like Methods), or politician, to understand
such things.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Dr J R Stockton
4g2000vbe.googlegroups.com>, Thu, 4 Jun 2009 20:40:03, Adam Peller
<pel...@gmail.com> posted:
>On Jun 4, 2:30�pm, Dr J R Stockton <reply0...@merlyn.demon.co.uk>
>wrote:
>> That is best done, in JavaScript, by using just the UTC methods and then
>> having all times-of-day (by default) zero.
>>
>> Replace � new Date(Y, M, D) �by � new Date(Date.UTC(Y, M, D))
>
>That assumes that all users of Dojo APIs will use getUTC* methods to
>pull months, dates, etc from the Date objects.
It assumes nothing like that. It says how date work using Date Objects
should be done.
> I don't see that
>happening. Whatever the case, that's not why I posted here. I was
>merely hoping to discuss this in the abstract, and the surprise a user
>might have to see this behavior from the Date constructor.
>
>In summary, my understandings are (may or may not have been covered in
>this thread)
>
>* During a daylight leap, using the local time constructor which is
>incapable of specifying timezones, offsets, or daylight savings rules,
>there's an hour on the clock that simply doesn't exist (e.g. midnight
>through 12:59am in the location on the date mentioned previously)
No. The constructor new Date with numeric arguments can be given any
date on the Calendar, with any time on the clock, (with milliseconds) ;
and it can generate any internal value for the Date Object.
Example : In the UK, new Date(88, 5, 5) sets the Object to 573264000000
which represents Wed Mar 02 1988 00:00:00 GMT+0000; but I can get
Tue Mar 02 0088 00:00:00 GMT+0000 with new Date(88+400, 2-4800, 2).
In places where Summer Time is used, however, there are seasonal
displacements in the relationship. In the REVERSE operation, Object to
local YMDHMS, there's a YMDH that cannot be obtained and another that
can be obtained in two ways. That matches the behaviour of LCT.
>* The behavior of the Date constructor, apparently, is unspecified and
>left to the host environment, which will choose some arbitrary
>replacement, in this case repeating the 23rd hour just prior to
>midnight -- yes, the same hour with the same offset from GMT -- is
>what I've seen on more than one platform
That matches real life, in Autumn. Make a brief appointment for
2009-10-25 01:30 here, and you will be obliged to arrive twice. Make
one for 2010-03-28 01:30 here, and you will be unable to comply.
>* This leads to all sorts of surprising behaviors, like setting a
>date, then immediately getting the date back and seeing that it
>doesn't match what you set. Or, call setHours(0) twice on the date
>object, and it will change the date each time. Fun.
>
>I'm not talking about best practices here, just the somewhat
>surprising behavior to anyone using Date(y,m,d). Yes, these are all
>very good reasons not to use the local Date constructor this way.
If you want to handle dates and times in JavaScript, don't use packaged
code. Write your own. You'll probably get all the errors they've had
and will have; but you can fix yours quicker.
If you want to be REALLY safe in all possible browsers, don't use Date
Objects (except for getting current UTC and for determining offsets from
UTC). Y M D to/from daycount is not difficult.
If you want to be REALLY REALLY safe in ALL possible browsers, don't use
Date Objects (except for getting current UTC).
Evertjan.
> If you want to be REALLY REALLY safe in ALL possible browsers, don't use
> Date Objects (except for getting current UTC).
>
If you want to be REALLY REALLY REALLY safe in ALL possible browsers,
use serverside programming.
Under ASP, even ASP-VBscript, you can use Javascript getTimezoneOffset()
to become independent of server localisation:
============== getGMT.asp ===================
<% ' VBscript
nowGMT = DateAdd("h", timezoneOffsetHours , Now)
Response.Write "It's: " & nowGMT
%>
<script language='javascript' runat='server'>
var timezoneOffsetHours = new Date().getTimezoneOffset()/60;
</script>
=============================================
Thomas 'PointedEars' Lahn
>> but unless I'm mistaken, the time
>> zone's name changes as well when it passes into summer time (CET -> CEST
>> in Thomas's case, I believe).
>
> Time Zones do not change seasonally. Therefore their names cannot
> change seasonally.
Ex falso quodlibet. From March to October the time zone is CEST (Central
European Summer Time) here (GMT+02:00), the rest of the year it is just CET
(Central European Time), GMT+01:00. You need to read up on the subject as
apparently you are not an expert of time zones either.
<http://en.wikipedia.org/wiki/Time_zone#Daylight_saving_time>
<http://en.wikipedia.org/wiki/Daylight_saving_time#Terminology>
PointedEars
Dr J R Stockton
7g2000vbi.googlegroups.com>, Fri, 5 Jun 2009 13:02:54, David Mark
<dmark....@gmail.com> posted:
>On Jun 4, 11:40�pm, Adam Peller <pel...@gmail.com> wrote:
>> * During a daylight leap, using the local time constructor which is
>> incapable of specifying timezones, offsets, or daylight savings rules,
>> there's an hour on the clock that simply doesn't exist (e.g. midnight
>> through 12:59am in the location on the date mentioned previously)
>
>The hour exists, but it is a tricky hour to name.
In Local Civil Time, one Spring "hour" representable by Y M D h does NOT
exist. Therefore, it needs no name other than "the missing hour".
And one Autumn "hour" representable by Y M D h exists twice. AIUI, by
Law, those two actual hours are discriminated in Civil notation by
adding (appending?) the letters A & B. Alas, AFAIK, that Law is only
German.
--
Dr J R Stockton
6 Jun 2009 17:50:17, Thomas 'PointedEars' Lahn <Point...@web.de>
posted:
You are ill-educated.
Wikipedia is not an authority on proper use of language.
The first cited article begins "A time zone is a region of the earth
that has uniform standard time"; the section on DST is mere additional
information.
The second cited section is incorrect, in paragraph 2. It should say,
for example, that Canada's Mountain Time Zone (a subset of the -7 Zone,
I think) uses as its local time designator MST in Winter and MDT in
Summer. The section is manifestly valueless, since it says that GMT
becomes BST in Summer. You should have noted that the point is already
made in the Discussion.
Much of that part of Wiki is written, manifestly, by Americans; a people
notorious for terminological inexactitude (here, in the non-Churchillian
sense).
--
Dr J R Stockton
, Sat, 6 Jun 2009 07:21:12, Evertjan. <exjxw.ha...@interxnl.net>
posted:
>Dr J R Stockton wrote on 05 jun 2009 in comp.lang.javascript:
>
>> If you want to be REALLY REALLY safe in ALL possible browsers, don't use
>> Date Objects (except for getting current UTC).
>>
>
>If you want to be REALLY REALLY REALLY safe in ALL possible browsers,
>use serverside programming.
I would not wish to assume that a server is always correctly set.
For a long while, files uploaded by FTP to my Web site's server at Demon
were timestamped with a drifty clock.
Borland's quasi-Usenet server was evidently adjusted for DST, for some
years, by altering the UTC clock rather than the value of LCT-UTC.
= =
I expect you have Dutch goods at home, with barcodes. Would you care to
check a few with <URL:http://www.merlyn.demon.co.uk/js-misc1.htm#BCode>?
Local codes should start with 8; coding of the next 6 digits depends on
the first digit; here I only have UPC codes starting with 0, UK EAN
codes starting with 5, and ISBN-13 starting with 9. No need to measure;
you should be able to see whether the widths I show are consistent with
your printed ones.
Thomas 'PointedEars' Lahn
>> Dr J R Stockton wrote:
>>> Conrad Lender posted:
>>>> but unless I'm mistaken, the time
>>>> zone's name changes as well when it passes into summer time (CET -> CEST
>>>> in Thomas's case, I believe).
>>> Time Zones do not change seasonally. Therefore their names cannot
>>> change seasonally.
>> Ex falso quodlibet. From March to October the time zone is CEST (Central
>> European Summer Time) here (GMT+02:00), the rest of the year it is just CET
>> (Central European Time), GMT+01:00. You need to read up on the subject as
>> apparently you are not an expert of time zones either.
>>
>> <http://en.wikipedia.org/wiki/Time_zone#Daylight_saving_time>
>> <http://en.wikipedia.org/wiki/Daylight_saving_time#Terminology>
>
> You are ill-educated.
You are a presumptuous idiot.
> Wikipedia is not an authority on proper use of language.
Neither are you.
PointedEars
Evertjan.
> In comp.lang.javascript message
> <Xns9C225F25...@194.109.133.242> , Sat, 6 Jun 2009 07:21:12,
> Evertjan. <exjxw.ha...@interxnl.net> posted:
>>Dr J R Stockton wrote on 05 jun 2009 in comp.lang.javascript:
>>
>>> If you want to be REALLY REALLY safe in ALL possible browsers, don't
>>> use Date Objects (except for getting current UTC).
>>>
>>
>>If you want to be REALLY REALLY REALLY safe in ALL possible browsers,
>>use serverside programming.
>
>
> I would not wish to assume that a server is always correctly set.
"My" servers in Ottawa are!
The nice thing about serverside time is that you can check it for your
own pages.
>
> For a long while, files uploaded by FTP to my Web site's server at
> Demon were timestamped with a drifty clock.
>
> Borland's quasi-Usenet server was evidently adjusted for DST, for some
> years, by altering the UTC clock rather than the value of LCT-UTC.
> = =
>
> I expect you have Dutch goods at home, with barcodes. Would you care
> to check a few with
> <URL:http://www.merlyn.demon.co.uk/js-misc1.htm#BCode>? Local codes
> should start with 8; coding of the next 6 digits depends on the first
> digit; here I only have UPC codes starting with 0, UK EAN codes
> starting with 5, and ISBN-13 starting with 9. No need to measure; you
> should be able to see whether the widths I show are consistent with
> your printed ones.
I will try to send you some.
Dr J R Stockton
, Sun, 7 Jun 2009 09:55:12, Evertjan. <exjxw.ha...@interxnl.net>
posted:
Received, compared, agreement. Thanks.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk DOS 3.3 6.20 ; WinXP.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.