Thanks, Ben - I figured you'd be the one to pick this up. (btw - how do you
pronounce your name?)
The reason I think it may be a bug is that the output of the test script
(sans assertion) is as follows:
Tue May 15 2012 19:21:53 GMT-0700 (PDT)
1326405600000 Thu Jan 12 2012 14:00:00 GMT-0500 (EST)
1326405600000 Thu Jan 12 2012 17:00:00 GMT-0500 (EST)
Two dates have identical getTime() values but different hours with the
*same* tzinfo (EST). Regardless of which TZ is the current one, that should
never happen, correct? It's a matter of internal consistency; one of those
lines has got to be wrong. (The bottom line is correct; the date appears to
be parsed as though the TZ is still America/LA)
Seth
On Tuesday, May 15, 2012 7:38:37 PM UTC-4, Ben Noordhuis wrote:
> > Hi all,
> >
> > Before I raised this as an issue on Node, I wanted to sanity-check it
> here.
> > Basically, I'm having an issue where the Date constructor/localizer lags
> > behind a change to process.env.TZ. Here's a script to reproduce what
> I'm
> > seeing:
> >
> > var assert = require('assert');
> >
> > // if either of these three lines is commented out, the problem goes
> away
> > process.env.TZ = 'America/Los_Angeles';
> > console.log(new Date().toString());
> > process.env.TZ = "America/New_York";
> >
> > // uncomment this and the problem goes away
> > //console.log(new Date().toString());
> >
> > // create a date by parsing a string
> > var d = new Date('2012-1-12 02:00 PM');
> >
> > // can also create the date this way
> > //var d = new Date(2012, 0, 12, 14);
> >
> > // print the date value and locale string
> > console.log(d.getTime() + " " + d.toLocaleString());
> >
> > // should create an identical date
> > var copy = new Date(d);
> >
> > // print the copy's value and locale string
> > // the values are the same, but the **strings are different**
> > console.log(copy.getTime() + " " + copy.toLocaleString());
> >
> > // here we see the date has been given the wrong value to begin with
> > assert.equal(d.getTime(), 1326394800000);
> >
> >
> > Hopefully this makes the problem clear - the script prints two dates
> with
> > identical ms values but differing toString() values. Admittedly, it
> seems
> > harsh to be jerking the TZ around like this, but I suspect there's a bug
> > here.
>
> It's not really a bug but a result of how the standard timezone
> functions work on UNIX systems.
>
> The date handling code in V8 implicitly calls tzset(3)[1] when you
> first convert a string to a date or vice versa.
>
> tzset() parses and caches the TZ environment variable. That means that
> you can set TZ just once, further changes won't get picked up. Even
> that may not work if Node's boot scripts did some date munging - which
> they almost never do, fortunately.
>
> [1] http://linux.die.net/man/3/tzset
>
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
