Leap Seconds in Javascript

Discussion in 'Javascript' started by Dr John Stockton, Jan 18, 2006.

  1. 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?

    --
    © John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
    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 moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
    Dr John Stockton, Jan 18, 2006
    #1
    1. Advertising

  2. JRS: In article <>, dated Thu, 19
    Jan 2006 10:58:46 remote, seen in news:comp.lang.javascript, Jasen Betts
    <> posted :
    >On 2006-01-18, Dr John Stockton <> wrote:
    >
    >> Is UNIX time_t specified as either with or without Leap seconds?


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


    >> 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?

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

    --
    © John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
    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 moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
    Dr John Stockton, Jan 19, 2006
    #2
    1. Advertising

  3. JRS: In article <>, dated Fri, 20 Jan
    2006 08:42:58 remote, seen in news:comp.lang.javascript, Jasen Betts
    <> posted :
    >On 2006-01-19, Dr John Stockton <> wrote:


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

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




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

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


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

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


    --
    © John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
    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 moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
    Dr John Stockton, Jan 20, 2006
    #3
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. tshad
    Replies:
    7
    Views:
    16,904
    tshad
    Mar 11, 2005
  2. 00_CP_D12
    Replies:
    3
    Views:
    8,873
    dilipv
    Feb 22, 2008
  3. Stu
    Replies:
    7
    Views:
    1,726
    Dave Thompson
    Mar 7, 2005
  4. Michael Tan
    Replies:
    32
    Views:
    928
    Ara.T.Howard
    Jul 21, 2005
  5. `p
    Replies:
    7
    Views:
    352
    Steve Litt
    Dec 14, 2005
Loading...

Share This Page