Off by an Hour Bug with day light savings time

I was writing some qunit tests around some gui controls that incorporate your datetimepicker, and I ran into a bug that has to do with day light savings time.

//initialize with no options
picker.datetimepicker();
picker.datetimepicker('setDate', new Date(2010, 0, 1));

will cause ‘12/31/2009 23:00’ to be displayed, one hour before. Performing the same test with an August date cause the correct date to be displayed.

I am on Mountain Standard Time GMT-0600. The incorrect dates are during Mountain DayLight Time GMT-0700

Thanks

[johnrmalone]

Hi @trentrichardson , I love your plugin. It’s been working great until November, when our automated tests started to fail. So far my research has led me here. What I’m attempting to do is have the datetime picker localized to the user, and using an alt field in ISO to be actually posted back to the server.

$(this).datetimepicker({
            altField : "#" + altFieldId,
            altFieldTimeOnly : false,
            altFormat : $.datepicker.ISO_8601,
            altTimeFormat : "HH:mm:ss.lZ",
            altSeparator : "T",
            ...

However, when a user selects a date such as 07/11/2013 1:25:10 p.m., (July 2013), the timezone at that point in time in Colorado was MDT. It is now MST due to daylight savings time.

So the problem is that when the iso date is posted back to the server, it’s -07:00, which is MST, when it should be -06:00 (MDT), which is the correct timezone offset for the date selected by the user.

So by the time it gets stored to the database and comes full circle back the the UI, it’s off by an hour.

Or at least that’s as far as I’ve gotten with my logic on this so far. This issue seems to be talking about a similar thing, but the discussion here seems to have waned.

Does anyone have any ideas about what we can do about this? I’m tempted to either manually adjust the datetime and re-set it, or detect when the date is changed on the control and change the timezone offset that the picker uses accordingly. But if there’s a plugin-level solution, I think I would much prefer that.

[smarcaurele]

Sorry Trent, I got distracted from this thread for a while. I agree that the calculations are the same. The point I was trying to make is that on the way out (getDate) there should be no extra parameters. On the way in (setDate) you could provide a flag indicating whether you want to adjust the time sliders or the timezone slider in your add-on, but on the way out you are just going to construct a time instance based on the state of the sliders. I don’t understand what an extra parameter on the getDate method would even do.