1/2 argument constructors with timezone do weird things

[danielrichman]

date.js lists this as a possible way to construct a date: timezoneJS.Date(utcMillis, [tz]): Return object with UTC time = utcMillis, in tz and states that getTime() returns UTC time.

However:

> a = new timezoneJS.Date(0, "Europe/London")
> a.getTime()
-3600000 // expect zero

I'm not sure if I've badly misinterpreted the documentation or this is broken. Indeed, this behaviour is even unit tested.

Some strange implications of this behaviour:

a = new timezoneJS.Date(2000, 6, 1, 0, 0, 0, "Europe/London")
a.toString() == "Fri, 30 Jun 2000 23:00:00 GMT"
for (i = 0; i < 1000; i++)
    a = new timezoneJS.Date(a, "Europe/London")
a.toString() == "Sat, 20 May 2000 07:00:00 GMT"

Finally, noting that my system/browser time is set to Europe/London;

(new timezoneJS.Date("Europe/London")).getTime()
1342523332306
(new timezoneJS.Date("Europe/Paris")).getTime()
1342519732306
(new timezoneJS.Date("Etc/UTC")).getTime()
1342526932306
(new Date()).getTime()
1342526932306
(a = (new timezoneJS.Date("Etc/UTC")), a.setTimezone("Europe/London"), a.getTime())
1342526932306

but I would expect all five of these numbers to be the same (the correct UNIX timestamp when I ran that was 1342526932)

[longlho]

Yeah initially I was thinking of the constructor where the last arg is tz and the rest are params corresponding to that tz but it seems to make more sense that when you pass in a utcMillis it should be in Etc/UTC. I'll take a look at this.

[danielrichman]

I've since had a stab at modifying the constructor. It's not finished (need to add some more tests), but after modifying the unit test that I linked too, the changes still pass all the others

https://github.com/danielrichman/timezone-js/commit/60afd176d47fbf41fedfd844c31c41ba6e885a6f

[longlho]

This comes down to the assumption of how we construct timezoneJS.Date object:

• If timezoneJS.Date got created based on a normal Date so that year, month, date... is fixed then utcMillis would be off (2012-08-01 00:00:00 UTC does not have the same utcMillis as 2012-08-01 00:00:00 EST).
• If timezoneJS.Date got created based on a normal Date so that utcMillis is fixed, then year, month, date... would be off.

I think for now the library sticks with the 1st assumption, so new Date(0) is 1970-01-01 UTC but same date in EST would be -5 * 3600 * 1000

[longlho]

fixed in e401a597e