problems with changing process.env.TZ at runtime

SethP

unread,

May 15, 2012, 6:44:45 PM5/15/12

to nod...@googlegroups.com

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.

Thanks,
Seth

Ben Noordhuis

unread,

May 15, 2012, 7:38:37 PM5/15/12

to nod...@googlegroups.com

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

SethP

unread,

May 15, 2012, 10:44:53 PM5/15/12

to nod...@googlegroups.com

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

Ben Noordhuis

unread,

May 16, 2012, 9:06:12 AM5/16/12

to nod...@googlegroups.com

On Wed, May 16, 2012 at 4:44 AM, SethP <kaio...@gmail.com> wrote:
> Thanks, Ben - I figured you'd be the one to pick this up. (btw - how do you
> pronounce your name?)

'North house' is a close enough approximation. :-)

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

Yes, that's a V8 bug. It's mostly* fixed in master.

Your example still won't work quite right (the assertion will fail)
unless you `export TZ="America/New_York"` before running the script.
That can't really be helped, I'm afraid.

* There is still a bug in timezone handling on Solaris.

SethP

unread,

May 16, 2012, 5:15:49 PM5/16/12

to nod...@googlegroups.com

On Wednesday, May 16, 2012 9:06:12 AM UTC-4, Ben Noordhuis wrote:

> Thanks, Ben - I figured you'd be the one to pick this up. (btw - how do you
> pronounce your name?)

'North house' is a close enough approximation. :-)

Thanks for clearing that up for everyone. Maybe that can go in the group FAQ? :o)

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

Yes, that's a V8 bug. It's mostly* fixed in master.

Your example still won't work quite right (the assertion will fail)
unless you `export TZ="America/New_York"` before running the script.
That can't really be helped, I'm afraid.

* There is still a bug in timezone handling on Solaris.

Good to know. I've abandoned my dumb approach and am now using node-time (which appears to have some oddities of its own lurking in the corner cases).

I figured something must be caching the TZinfo; here's a script that shows some perplexing behavior on OS X:

var d;

console.log(new Date().toString());

process.env.TZ = 'America/Los_Angeles';