arshaw / xdate

A Modern JavaScript Date Library
http://arshaw.com/xdate/
GNU General Public License v2.0
681 stars 81 forks source link

Creating date with 'new XDate([date], true)' does not automatically coerce the date as would be expected #16

Closed BlazeCell closed 11 years ago

BlazeCell commented 12 years ago

When I use the code below:

date = new XDate('2012-09-21');
$dateOutput.text(date.toString('yyyy-MM-dd HH-mm-ss'));

I get an output of:

2012-09-21 00:00:00

which is what I expect.

However, when I alter the code to:

date = new XDate('2012-09-21', true);
$dateOutput.text(date.toString('yyyy-MM-dd HH-mm-ss'));

I get an output of:

2012-09-21 07:00:00

Which not what I'm expecting. I expect that if I'm creating a date in UTC mode, that whatever value I use to create my date will be used to create the date in UTC mode; not create the date and then convert that date to UTC mode.

I found the problem code at line 119 inside xdate.dev.js. I changed the line from:

setUTCMode(xdate, utcMode);

to

setUTCMode(xdate, utcMode, true);

and now I get the expected behavior.

So now, with the change, the following code:

date = new XDate('2012-09-21', true);
$dateOutput.text(date.toString('yyyy-MM-dd HH-mm-ss'));

results in an output of:

2012-09-21 00:00:00

If you need me to, I'll make a pull request, but I figured it was a pretty minor change so I'm just posting it here for now.

BlazeCell commented 12 years ago

Update: Upon further fiddling with this change, I've found additional pieces that weren't behaving as expected. More changes will need to be made for this to work properly.

arshaw commented 11 years ago

This issue is from a while ago, sorry about that. I looked into your issue, and everything's working fine on my end. The test added in this commit is passing: 919d3a9e872a301c9db156995da506277a698377

Is is possible you were misinterpreting your debug output?