jQuery-Timepicker-Addon: 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

About this issue

Original URL
State: open
Created 11 years ago
Comments: 22 (9 by maintainers)

Commits related to this issue

Fix for #588 and #213 dealing with Daylight Savings Time — committed to trentrichardson/jQuery-Timepicker-Addon by trentrichardson 11 years ago
Fix for #588 DST bug — committed to trentrichardson/jQuery-Timepicker-Addon by trentrichardson 11 years ago
#588 work on getDate setDate timezone conversions — committed to trentrichardson/jQuery-Timepicker-Addon by trentrichardson 11 years ago

Most upvoted comments

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.

johnrmalone on Dec 5, 2014