Daylight Savings leap bugs?

D

Dr J R Stockton

In comp.lang.javascript message <b54b40bb-283a-4275-ac99-baad7f8d2f18@q1
4g2000vbn.googlegroups.com>, Wed, 3 Jun 2009 15:57:24, Adam Peller
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.
 
A

Adam Peller

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.
 
D

David Mark

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.
 
D

Dr J R Stockton

In comp.lang.javascript message <-a6dna9D1_BaD7XXnZ2dnUVZ8o-
(e-mail address removed)>, Fri, 5 Jun 2009 05:36:37, Conrad Lender
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.
 
D

Dr J R Stockton

In comp.lang.javascript message <c71f1b56-2804-447b-9b64-db27d846eb69@e2
4g2000vbe.googlegroups.com>, Thu, 4 Jun 2009 20:40:03, Adam Peller
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).
 
E

Evertjan.

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.

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>
=============================================
 
D

Dr J R Stockton

In comp.lang.javascript message <efd26a03-cd4b-41ca-9383-eb837a53da95@q3
7g2000vbi.googlegroups.com>, Fri, 5 Jun 2009 13:02:54, David Mark
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.
 
T

Thomas 'PointedEars' Lahn

Dr said:
Conrad Lender posted:

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
 
D

Dr J R Stockton

In comp.lang.javascript message <[email protected]>, Sat,
6 Jun 2009 17:50:17 said:
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.

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).
 
D

Dr J R Stockton

In comp.lang.javascript message <[email protected]>
Dr J R Stockton wrote on 05 jun 2009 in comp.lang.javascript:


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.
 
E

Evertjan.

Dr J R Stockton wrote on 06 jun 2009 in comp.lang.javascript:
In comp.lang.javascript message



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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top