Prev: Errore proprietà charcode jquery...
Next: complete page rewriting
From: Thomas 'PointedEars' Lahn on 22 Jul 2010 07:44
David Mark wrote:

> Thomas 'PointedEars' Lahn wrote:
>> date: new Date(2010, 6, 1)
>
> Careful on this one. In rare cases, in some time zones, this can
> underflow to the previous day (and month in this example). Has to do
> with DST, IIRC.

You must be mistaken. According to
<http://www.worldtimezone.org/daylight.html>, there is not going to be any
DST switch anywhere on this planet near *July* 1st of the Gregorian
calendar. Indeed, it does not make any sense to switch to or from
*Daylight* Saving Time/*Summer* Time near the mid (solstice) of summer
(Northern Hemisphere) or winter (Southern Hemisphere) rather than near the
beginning or end of either one (equinox).

Also, assuming that there would be such a switch date as you suggest, a date
underflow would be non-standard behavior, an implementation (or version of
an implementation) that is FUBAR and not worth considering. For example,
the next switch from Central European Summer Time (CEST) back to CET is
going to be at 2010-10-31 03:00:00.000 GMT+02:00 CEST here; but (new
Date(2010, 9, 31)).getDate() yields 31 in all 6 major implementations (do I
need to name them?) here, of course.

So, since *you* are making that claim, I daresay unto you "Show me where
(and when) it fails." :)

> In other words, if it will only be used to calculate time spans, it's
> fine.

Wouldn't it be the other way around?


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
From: John G Harris on 22 Jul 2010 09:43
On Thu, 22 Jul 2010 at 03:25:55, in comp.lang.javascript, David Mark
wrote:
>On Jul 22, 4:54�am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
>wrote:
>
>[...]
>
>> � � � date: � �new Date(2010, 6, 1)
>
>Careful on this one. In rare cases, in some time zones, this can
>underflow to the previous day (and month in this example). Has to do
>with DST, IIRC. Of course, that won't matter unless you are going to
>display it, convert it to a string, retrieve the day, etc. In other
>words, if it will only be used to calculate time spans, it's fine.
>
>I have code that fixes this
<snip>

new Date(2010, 6, 1, 12, 0, 0)
fixes it.

John
--
John Harris
From: Thomas 'PointedEars' Lahn on 22 Jul 2010 17:13
John G Harris wrote:

> David Mark wrote:
>> Thomas 'PointedEars' Lahn wrote:
>> [...]
>>> date: new Date(2010, 6, 1)
>> Careful on this one. In rare cases, in some time zones, this can
>> underflow to the previous day (and month in this example). Has to do
>> with DST, IIRC. Of course, that won't matter unless you are going to
>> display it, convert it to a string, retrieve the day, etc. In other
>> words, if it will only be used to calculate time spans, it's fine.
>>
>> I have code that fixes this
> <snip>
>
> new Date(2010, 6, 1, 12, 0, 0)
> fixes it.

No, if there would be a *general* problem with the call above (and there is
not, possibly borken *tzdata* implementations in the *OS* aside), then your
call would not be a fix; it could, at most, slightly reduce the likelihood
that a problem could occur.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: David Mark on 22 Jul 2010 18:46
On Jul 22, 9:43 am, John G Harris <j...(a)nospam.demon.co.uk> wrote:
> On Thu, 22 Jul 2010 at 03:25:55, in comp.lang.javascript, David Mark
> wrote:>On Jul 22, 4:54 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
> >wrote:
>
> >[...]
>
> >>       date:    new Date(2010, 6, 1)
>
> >Careful on this one.  In rare cases, in some time zones, this can
> >underflow to the previous day (and month in this example).  Has to do
> >with DST, IIRC.  Of course, that won't matter unless you are going to
> >display it, convert it to a string, retrieve the day, etc.  In other
> >words, if it will only be used to calculate time spans, it's fine.
>
> >I have code that fixes this
>
>   <snip>
>
>   new Date(2010, 6, 1,  12, 0, 0)
> fixes it.
>

I don't recall that it did and would be surprised to find out that is
the case (as I imagine that I would have tried it). I'll try to dig
up a date and TZ that demonstrates the issue.
From: David Mark on 22 Jul 2010 18:53
On Jul 22, 7:44 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> David Mark wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> date:    new Date(2010, 6, 1)
>
> > Careful on this one.  In rare cases, in some time zones, this can
> > underflow to the previous day (and month in this example).  Has to do
> > with DST, IIRC.
>
> You must be mistaken.

Hardly, I've seen the bug in action.

> According to
> <http://www.worldtimezone.org/daylight.html>, there is not going to be any
> DST switch anywhere on this planet near *July* 1st of the Gregorian
> calendar.

I didn't mean to imply that there was a problem with that specific
date. Quite the contrary, the problem dates are few and far between,
so it would have been extraordinarily bad luck for you to have hit one
in your example.

> Indeed, it does not make any sense to switch to or from
> *Daylight* Saving Time/*Summer* Time near the mid (solstice) of summer
> (Northern Hemisphere) or winter (Southern Hemisphere) rather than near the
> beginning or end of either one (equinox).

That's irrelevant, but sorry for any confusion.

>
> Also, assuming that there would be such a switch date as you suggest, a date  
> underflow would be non-standard behavior, an implementation (or version of
> an implementation) that is FUBAR and not worth considering.

The problem I saw existed in at least one major desktop browser
(latest version at the time) on Windows. We did discuss this problem
here as well (back around October of last year).

> For example,
> the next switch from Central European Summer Time (CEST) back to CET is
> going to be at 2010-10-31 03:00:00.000 GMT+02:00 CEST here; but (new
> Date(2010, 9, 31)).getDate() yields 31 in all 6 major implementations (do I
> need to name them?) here, of course.

You have to change your time zone settings to see the problem. I
don't recall which time zones were affected.

>
> So, since *you* are making that claim, I daresay unto you "Show me where
> (and when) it fails." :)

It's been posted here. Perhaps Google for comp.lang.javascript + date
+ underflow + Stockton + Mark, etc.

>
> >  In other words, if it will only be used to calculate time spans, it's
> >  fine.
>
> Wouldn't it be the other way around?
>

No. It's the serialization and presentation that get busted.
Internally, it's just a number. Fudging the number (e.g. the Dojo
example) is unnecessary and will likely lead to incorrect
calculations.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Errore proprietà charcode jquery...
Next: complete page rewriting