timezoneJS.Date()

[happymap]

Hi,

I am pretty confused about the below example in the doc since I got different timestamps during testing.

"var dtA = new timezoneJS.Date(2007, 9, 31, 10, 30, 'America/Los_Angeles'); var dtB = new timezoneJS.Date(2007, 9, 31, 12, 30, 'America/Chicago'); // Same timestamp dtA.getTime(); => 1193855400000 dtB.getTime(); => 1193855400000"

The timezoneJS.Date(time, timezone)

This function, in my understanding, should return the date object which indicates the "time" in that "timezone". But in fact, it first initializes a Date based on user browser's time zone and then converts it into the specified "timezone".

Could someone helps me out?

Thanks!

[nareshbhatia]

As far as I can see it is working correctly. Here's a slightly modified version of the code:

var dtA = new timezoneJS.Date(2007, 9, 31, 10, 30, 'America/Los_Angeles');
var dtB = new timezoneJS.Date(2007, 9, 31, 12, 30, 'America/Chicago');
// Same timestamp
console.log(dtA.getTime() + ": " + new Date(dtA.getTime()));
console.log(dtB.getTime() + ": " + new Date(dtB.getTime()));

Ourput is

1193851800000: Wed Oct 31 2007 13:30:00 GMT-0400 (Eastern Daylight Time)
1193851800000: Wed Oct 31 2007 13:30:00 GMT-0400 (Eastern Daylight Time)

While the timestamps don't match the docs (which they should, may be an error in docs), but you indeed get the expected times - here printed in EDT, but if you convert to CDT and PDT - they are picking up the intended values.

The behavior that you are talking about (date initialization using browser's time zone) happens when you specify the date as a string:

var dtC = new timezoneJS.Date('10/31/2007 12:30', 'America/Chicago');
console.log(dtC.getTime() + ": " + new Date(dtC.getTime()));

In this case the output is:

1193848200000: Wed Oct 31 2007 12:30:00 GMT-0400 (Eastern Daylight Time)

which is clearly different and unexpected! I had fallen into this trap myself and don't find this constructor to be very useful.

[longlho]

It's true that this is rather confusing, deprecating this would make the library incompatible with native Date object though.

It's very hard to fix this behavior, since without native Date it'd be hard to convert anything to utcMillis which is used to look up timezone from tzdata sometimes. Basically this will require a huge amount of refactoring and I simple don't have the time for it right now.

[nareshbhatia]

A simple solution would be to just document this behavior very clearly. It would shorten the leaning time for future users. I know I wasted many hours trying to figure this out.

[longlho]

Yeah that should serve well as a first step. Wanna pull request? :)

[lumbric]

I added some (hopefully usefull) hints to the README in pull request #89.

[kdimatteo]

The following:

var dt = new window.timezoneJS.Date(new Date());
console.debug(dt.toString());
dt.setTimezone('America/Los_Angeles');
console.debug(dt.toString());

Yields:

2013-07-18 19:09:30 //now
2013-07-18 16:09:30 //now... in LA

[longlho]

hmm looks correct?

[nareshbhatia]

That looks correct. You are in Eastern timezone and the time difference with LA is 3 hours. You are seeing 19:09 and 16:09 respectively which is correct.

[kdimatteo]

Yes, providing an example of correct usage. Thanks @nareshbhatia and @longlho