Daylight Savings leap bugs?

Discussion in 'Javascript' started by Adam Peller, Jun 3, 2009.

  1. Adam Peller

    Adam Peller Guest

    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

    >>> 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
    Adam Peller, Jun 3, 2009
    #1
    1. Advertising

  2. Adam Peller wrote:
    > 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
    Thomas 'PointedEars' Lahn, Jun 3, 2009
    #2
    1. Advertising

  3. Adam Peller

    Adam Peller Guest

    On Jun 3, 11:00 am, 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.


    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
    Adam Peller, Jun 3, 2009
    #3
  4. Adam Peller

    Doug Miller Guest

    In addition to the errors already pointed out by T. Lahn, there's this one:

    In article
    <>, Adam
    Peller <> 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
    Doug Miller, Jun 3, 2009
    #4
  5. Adam Peller

    Adam Peller Guest

    On Jun 3, 12:16 pm, (Doug Miller) wrote:
    > 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)
    Adam Peller, Jun 3, 2009
    #5
  6. Adam Peller

    David Mark Guest

    On Jun 3, 9:54 am, Adam Peller <> wrote:

    [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.
    David Mark, Jun 3, 2009
    #6
  7. Adam Peller wrote:
    > 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.

    >
    > Whoa, hold on. [...] 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.


    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
    Thomas 'PointedEars' Lahn, Jun 3, 2009
    #7
  8. Adam Peller

    Doug Miller Guest

    In article <>, Adam Peller <> wrote:
    >On Jun 3, 12:16=A0pm, (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. ...
    Doug Miller, Jun 3, 2009
    #8
  9. In comp.lang.javascript message <54429e6d-86a8-48ff-8d52-f7e6cd9dafa4@o1
    4g2000vbo.googlegroups.com>, Wed, 3 Jun 2009 06:54:21, Adam Peller
    <> 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, Jun 3, 2009
    #9
  10. In comp.lang.javascript message <>, Wed,
    3 Jun 2009 17:00:35, 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.

    "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, Jun 3, 2009
    #10
  11. In comp.lang.javascript message <7f50ec38-2227-4f01-9090-3ad1a6c355f8@o1
    4g2000vbo.googlegroups.com>, Wed, 3 Jun 2009 09:08:25, Adam Peller
    <> 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/?.?
    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)
    Dr J R Stockton, Jun 3, 2009
    #11
  12. Adam Peller

    Adam Peller Guest

    On Jun 3, 2:20 pm, David Mark <> 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.
    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, Jun 3, 2009
    #12
  13. Adam Peller

    Adam Peller Guest

    On Jun 3, 4:24 pm, (Doug Miller) wrote:
    > >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. :)
    Adam Peller, Jun 4, 2009
    #13
  14. Adam Peller

    David Mark Guest

    On Jun 3, 6:57 pm, Adam Peller <> wrote:
    > On Jun 3, 2:20 pm, David Mark <> 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?
    David Mark, Jun 4, 2009
    #14
  15. Adam Peller

    Adam Peller Guest

    On Jun 3, 8:54 pm, David Mark <> wrote:
    > 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.
    Adam Peller, Jun 4, 2009
    #15
  16. Adam Peller

    David Mark Guest

    On Jun 3, 11:39 pm, Adam Peller <> wrote:
    > On Jun 3, 8:54 pm, David Mark <> 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.
    David Mark, Jun 4, 2009
    #16
  17. 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?

    > "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
    Thomas 'PointedEars' Lahn, Jun 4, 2009
    #17
  18. In comp.lang.javascript message <2d9162d4-7b3c-4a79-8d49-0dc01dd74a36@t1
    0g2000vbg.googlegroups.com>, Wed, 3 Jun 2009 11:20:48, David Mark
    <> posted:
    >On Jun 3, 9:54 am, Adam Peller <> wrote:
    >
    >[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.



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

    --
    (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, Jun 4, 2009
    #18
  19. Adam Peller

    Evertjan. Guest

    Thomas 'PointedEars' Lahn wrote on 04 jun 2009 in comp.lang.javascript:

    > 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)
    Evertjan., Jun 4, 2009
    #19
  20. In comp.lang.javascript message <>, Thu,
    4 Jun 2009 12:16:55, Thomas 'PointedEars' Lahn <>
    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.

    <http://www.bbc.co.uk/programmes/b00904tn>
    Dr J R Stockton, Jun 4, 2009
    #20
    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. Ryan Ternier
    Replies:
    1
    Views:
    1,461
    Ryan Ternier
    Oct 14, 2005
  2. Svante Nicholas Arvedahl

    Daylight savings problem

    Svante Nicholas Arvedahl, Oct 20, 2003, in forum: Java
    Replies:
    9
    Views:
    4,949
    Svante Nicholas Arvedahl
    Oct 24, 2003
  3. Hariharan.A
    Replies:
    0
    Views:
    1,722
    Hariharan.A
    Feb 25, 2004
  4. lordy
    Replies:
    3
    Views:
    1,891
    lordy
    Jul 14, 2006
  5. js
    Replies:
    1
    Views:
    779
Loading...

Share This Page