Leap Seconds in Javascript

[Dr John Stockton]

I'm starting a new thread, for clarity.

I'm assuming that it's ECMA-262 3rd Edn (1999) that we should be using
for Web pages; that 4th Edn (what's its present status? is it
available?) is too advanced for compatibility with many browsers in
present-day use; that Web authors should be aware of what JScript and
..NET may do, but cannot rely on it; and that MS documents describe the
latest MS code as distinct from agreed standards.


ECMA-262, 3rd Edn, Sec 15.9.1.1 says "Leap seconds are ignored" and that
there are exactly 86,400,000 milliseconds per day. (It overrides that
in 15.9.1.9 #1 by +-3,600,000 ms for Summer Time changes.)


It appears that at least some Linux browsers get the OS to do at least
some conversions between Y M D h m s and DateObject.valueOf(); and that
the OS, having access to a Leap Second database, does the
conversion according to the rules in force at the date in question. At
present, there have been 23 positive (and no negative) Leap seconds
since Epoch at UTC 1970.0, the first being 1972-06-30 23:59:60 UTC.

(( Systems not recently updated may not know of
the Leap Second preceding 2006.0 UTC ))


In such systems, any code which assumes that new Date(Y, M, D)
returns a multiple of 864e5 give or take the Time Zone Offset is liable
to error, except when suitably rounded; 23 seconds may seem unimportant,
but it can put the result into the wrong minute, hour, day, month, or
year.


ISTM that suppliers of non-compliant browsers should be notified
appropriately, with examples of problems caused.


It is likely that a number of routines on my pages will FAIL on browsers
that show Leap Seconds.


Is UNIX time_t specified as either with or without Leap seconds?


IMHO, the existing (ECMA3 at least) Date Object Methods should ignore
Leap Seconds, now and in al future versions. But there could be an
added Method, matching getTimezoneOffset, which would return either the
number of Leap Seconds since 1970 or the difference TAI-UTC (ten
greater).


ECMA also requires that the current Summer Time rules are applied for
all dates; it seems that such browsers can also get that wrong, though
the effects may be less serious. Americans can test 31st March and 1st
November of 2006 and 2007.



Comments?

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Thu, 19
Jan 2006 10:58:46 remote, seen in Jasen Betts

First one must define UNIX ... Linux & POSIX are related terms.

.NOTES
. POSIX.1 defines seconds since the Epoch as a value to
. be interpreted as the number of seconds between a
. specified time and the Epoch, according to a formula
. for conversion from UTC equivalent to conversion on
. the naiive basis that leap seconds are ignored and all
. years divisible by 4 are leap years. This value is
. not the same as the actual number of seconds between
. the time and the Epoch, because of leap seconds and
. because clocks are not required to be synchronised to
. a standard reference. The intention is that the
. interpretation of seconds since the Epoch values be
. consistent; see POSIX.1 Annex B 2.2.2 for further
. rationale.

Well, I cannot say who I think must have decided that; it would annoy RW
again.

But using the Julian Calendar in a standard written about four centuries
since the Papal Bull and over two since the Calendar Acts does seem
ludicrous.

.CONFORMING TO
. SVr4, SVID, POSIX, X/OPEN, BSD 4.3
. Under BSD 4.3, this call is obsoleted by gettimeof-
. day(2). POSIX does not specify any error conditions.
.
.SEE ALSO
. date(1), gettimeofday(2), ctime(3), ftime(3)

I guess that means Linux is breaking the standard

Linux is probably breaking a POSIX standard; though without other tests
we cannot rule out that Linux is keeping "GMT" without Leap Seconds
*and* providing a Leap Second database, which the foolish browser is
actually using. Linux also needs to break the standard in respect of AD
2100, 2200, ... .

(meant to apply to the whole article, of course)

the historical rules are the current OS setting for handling summer time
(so the it can render the timestamps on files correctly etc...)
Do you mean that javascript should apply the current rules for future dates
to the past (instead of the "current" rules)?
Yes.

what does ECMA actually say.

Exactly that, in more words than I care to retype in full.

Condensing, except in quotes :-

The Adjustment "must depend on only four things:"
(1) Time of year
(2) Whether Leap Year
(3) Weekday of Jan 1st
(4) Location.

... "just whether daylight saving time would have been in effect if
the current" DST "algorithm had been used at the time." ...


Therefore, 2006/07 will be additionally amusing, when some US systems
use the old rules throughout, some the new rules throughout, and some
update their rule-base when it's not Winter 06/07.


One wants the full historic rules, especially the Summer Time ones, for
the proper interpretation of old datestamps (which should be held
independently of Summer); but one wants a GMT-like scale for easy
calculation.

In fact, one should use the UTC functions in javascript wherever the
application permits - they're simpler and faster.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Fri, 20 Jan
2006 08:42:58 remote, seen in Jasen Betts

at the time it was written time_t was typically as 32 bit signed integer

A good point.

(and apparently still is on my machine) good until

Tue Jan 19 03:14:07 UTC 2038 (dependant on leap seconds)

Which may catch out a few New Zealanders who stay up to 3 a.m. to check
the event, see nothing, and get it the following afternoon. And some
Americans, who will get it the previous evening.

so all 4-divisible years which can be represented are leap years.



that scenario was to be my next question.

Let's see what your 'neighbours' in NSW do when their current Summer
Time is extended from March 26th to April 2nd for the Games. Maybe they
think that extending Summer Time will improve the weather.

or the milisecond count, that's probably the fastest.

When possible; no need for a Date Object then. But I was thinking of
calculations like calendars, for which TZ & DST are irrelevant.