Time zone handling?

[kaspervidebaek]

I have a datetimepicker:

        $("#editnewsitem #from_picker").datetimepicker({
            dateFormat: "dd-mm-yy",
            timeFormat: "hh:mm",
            stepMinute: 5,
            useLocalTimezone: false,
            defaultTimezone: '+0000'
        });

Which I at some point want to set to a Date-object:

$("#editnewsitem #from_picker").datepicker('setDate', new Date(from));

This date object prints the following:

Sun May 23 2004 16:25:10 GMT+0200 (Romance Daylight Time)

The result printed by the picker is the following:

My overall goal is for the time format to be shown in UTC time (May 23rd 2004 14:25) which I believe I've indicated by using "useLocalTimezone" being false and "defaultTimezone" set to +0000 - also the default parameters.

I'm wondering if I'm doing something wrong, if it is broken, or if I'm misunderstanding the point of these timezone parameters? It seems that no matter what I set them to, the picker always uses the timezone set in my browser.

[trentrichardson]

I think what you're experiencing is how javascript (atleast in the browser) handles dates. The timezone is simply an offset from UTC, so I would suggest create the new date, get the timezone offset, then subtract the offset back off the time. So:

var dt = new Date(from),
    offset = dt.getTimezoneOffset();// returns minutes

dt.setMinutes(dt.getMinutes() - offset);
$("#editnewsitem #from_picker").datetimepicker('setDate', dt);

I haven't run this code so beware.. The timezone you will see from dt will still be +0200, but you have subtracted from it so it will appear in the datetime picker as UTC.

[kaspervidebaek]

Yes, this is the way I'm fixing it currently - I will of course also have to get the new date objects when submitting, and then have to re-add the subtracted minutes after user choose a time for it to not be submitted wrongly to the server.

Overall, I would think that such things was handled by the add on, if setting the correct timezone parameters?

[trentrichardson]

You are correct, it should be handled by the plugin. I think the overall issue has been so far trying not to break datepicker and it's methods (like setDate), and other than computing the offset there is no way to set the timezone in a js Date object. The getDate and setDate to me seem to be the trouble areas and is something I am trying to work out. Any proposed solutions are greatly appreciated.

My one thought is provide an optional second parameter to setDate for timezone. If it exists, compute the offset.

On the getDate it could use the set timezone (if timezone isn't being used then defaultTimezone option is used). Bad part is making this change may not be backwards compatible..

If you have a spare moment I would love your feedback.

[kaspervidebaek]

Adjusting the getTime and setTime functions would works, at least for this use-case, and might be the least invasive way to solve it.

Another solution would be to treat it as a display problem. Do not adjust anything when dates are set - since the date objects are actually correct - we should instead adjust whenever output is given to the user - my first attempt at a quick fix was to start adjusting the internal timeFormat function of the library - however I quickly realized that It will cause all sorts of trouble, especially since dates and times seem to be separately handled.

I really like the way that moment.js allowed me to handle the problem, maybe that can be used as inspiration?

moment(new Date()).format('MM/DD-YYYY, H:mm:ss') // Prints the current time according to my own timezone
moment(new Date()).utc().format('MM/DD-YYYY, H:mm:ss') // Prints the current UTC time

[trentrichardson]

I think I follow.. You're saying timepicker handles it ok, just when going to display the offset takes place. You are right on the point that date and time are handled separately. This does present a bit of a hurdle as well. I know the known issue comes from a few different angles.

1. Local timezone input, local timezone output, no big deal, nothing needs to change
2. Your situation where you would like it to be UTC (or whichever offset), even though timezone is not being specified as an option (showTimezone: false and timeFormat doesn't include z)
3. Timezone is specified with showTimezone

I think possibly for for 2 and 3 we might could use routine similar to when we call $('#dp').datetimepicker('getDate'):

// if timezone is set, use it, else use the default (+0000)
var preferred_offset = tp_inst.timezone || tp_inst._defaults.timezone,
    current_offset = dp_date.getTimezoneOffset(),
    offset_diff = current_offset - preferred_offset;

dp_date.setMinutes(dt.getMinutes() - offset);

So, in your case since the user does not enter a timezone in the picker you just set defaultTimezone to "+0000", and getDate returns as UTC.

Scenario 3 timezone is set from the picker, so it is used over defaultTimezone option.

Then, useLocalTimezone:true will set defaultTimezone if it is not already set. I think with this it would be mostly backwards compatible, and like your case you are consciously altering timezone, so you would be aware of it.

Sorry for the brain dump. I'm still thinking this through with caution..

[jmls]

how far did you get with your thinking ? I am struggling with timezones and offsets right now ;)

[trentrichardson]

We wrote some tests since and I think we are pretty close on how offsets are handled.

I boils down to this: Javascript Date objects on the browser will always show the local timezone, so whatever timezone in the timepicker is set to, the offset will be applied to the local time so that they are the same UTC value.

So 4:30 -0400 and 3:30 -0500 are the same time. So if your local timezone is -0400, and the datetimepicker is set to 3:30 -0500, getDate will return to you 4:30 -0400 because it can't actually change the timezone, just apply the offset difference.

[jmls]

many thanks for such a quick response. Can I assume then that the code is
not yet ready ? And is there a problem with the current version ? - at the
moment, if I select 28/09/2013, with a time of 12:00:00 and a timezone of
+06:00 , getDate gives me "Thu Sep 26 2013 12:00:00 GMT+0100 (GMT Daylight
Time) "

Or should I be getting the current timezone and applying my own offsets ?
If so, how can I get what the current timezone is ?

thanks again

On 26 September 2013 13:14, Trent Richardson notifications@github.comwrote:

We wrote some tests since and I think we are pretty close on how offsets
are handled.

I boils down to this: Javascript Date objects on the browser will always
show the local timezone, so whatever timezone in the timepicker is set to,
the offset will be applied to the local time so that they are the same UTC
value.

So 4:30 -0400 and 3:30 -0500 are the same time. So if your local timezone
is -0400, and the datetimepicker is set to 3:30 -0500, getDate will return
to you 4:30 -0400 because it can't actually change the timezone, just apply
the offset difference.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/573#issuecomment-25162652
.

Julian Lyndon-Smith
IT Director,
dot.r
http://www.dotr.com

"The bitterness of poor quality remains long after the sweetness of low
price is forgotten”

Follow dot.r on http://twitter.com/DotRlimited

[trentrichardson]

By your response it sounds like a bug.. when I go here, under Examples tab near the bottom there is an example with setDate and getDate buttons:
http://trentrichardson.com/examples/timepicker/

and enter 28/09/2013 12:00 am +0600 (00:00) and click getDate I get Fri Sep 27 2013 14:00:00 GMT-0400 (EDT)

I am -0400, which would 10 hour difference, and it backs up 10 hours to 14:00. This is the desired action.

And just to make certain, you are using 24hr format? (the capital H in your timeFormat) Also what does the above example result to for you?

[jmls]

I have this code :

var datePicker = this.$().datetimepicker(
{
dateFormat : 'dd/mm/yy',
timeFormat : 'HH:mm:ss',
showTimezone: true,
onClose : function(selectedDate) {
var newDate = $(this).datepicker('getDate');
console.log(selectedDate,newDate,newDate.toISOString());
},

});

this is the output after selecting 26/09/2013 12:00:00 -10:00
26/09/2013 12:00:00 Thu Sep 26 2013 12:00:00 GMT+0100 (GMT Daylight
Time)2013-09-26T11:00:00.000Z

On 26 September 2013 13:33, Trent Richardson notifications@github.comwrote:

By your response it sounds like a bug.. when I go here, under Examples tab
near the bottom there is an example with setDate and getDate buttons:
http://trentrichardson.com/examples/timepicker/

and enter 28/09/2013 12:00 am +0600 (00:00) and click getDate I get Fri
Sep 27 2013 14:00:00 GMT-0400 (EDT)

I am -0400, which would 10 hour difference, and it backs up 10 hours to
14:00. This is the desired action.

And just to make certain, you are using 24hr format? (the capital H in
your timeFormat) Also what does the above example result to for you?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/573#issuecomment-25163663
.

Julian Lyndon-Smith
IT Director,
dot.r
http://www.dotr.com

"The bitterness of poor quality remains long after the sweetness of low
price is forgotten”

Follow dot.r on http://twitter.com/DotRlimited

[PeterWone]

I fixed this, fixed passthrough option value requests and added a method for getting the zone interactively set by the user, but never having used this git business before I can’t figure out how to check it in.

Sent from Windows Mail

From: Trent Richardson
Sent: ‎Thursday‎, ‎September‎ ‎26‎, ‎2013 ‎10‎:‎33‎ ‎PM
To: trentrichardson/jQuery-Timepicker-Addon

By your response it sounds like a bug.. when I go here, under Examples tab near the bottom there is an example with setDate and getDate buttons:
http://trentrichardson.com/examples/timepicker/

and enter 28/09/2013 12:00 am +0600 (00:00) and click getDate I get Fri Sep 27 2013 14:00:00 GMT-0400 (EDT)

I am -0400, which would 10 hour difference, and it backs up 10 hours to 14:00. This is the desired action.

And just to make certain, you are using 24hr format? (the capital H in your timeFormat) Also what does the above example result to for you?

—
Reply to this email directly or view it on GitHub.

[trentrichardson]

Hey Peter,

• Just fork this repository (use Fork button on the top right of the page). This will make a copy of this project on your account.
• Clone a working copy on to your computer
• Checkout the "dev" branch, this is where we develop and test before going live with updates.
• Make your changes to the code, commit, then push back to your repo
• send a pull request to me (This can be done on the website)

Also I haven't used it but the Github windows app may make this much simpler.. although in the background it follows those basic steps.

If this doesn't work and you want to just document your changes (code, line numbers, etc to apply changes) I can do it for you.

Thanks!

[ghost]

Was this ever resolved? I've encountered a situation where I need the Now button to display the current date/time in UTC instead of using the local timezone. Thanks.

[datpham23]

Still facing this issue in v1.4.4, anyone has a work around?

[matts1189]

+1

[minusdavid]

Also have this problem with v1.4.3, but it looks like it's supposed to work in v1.6.1, as it works well on http://trentrichardson.com/examples/timepicker/#timezone_examples at the "Define your own timezone options" section.

I would love to have "Now" go to Now in UTC...

[minusdavid]

Although it's worth mentioning the "You may also use timezone string abbreviations for values..." example doesn't work with the "Now" button.

Javascript really doesn't seem to like timezones.

[trentrichardson]

Just an update here, the example of "You may also use timezone string abbreviations for values..." was removed in the dev branch a while back, I just haven't had a chance to update master. The issue with that example was that there would be no way to accurately calculate the time offset for that timezone. For instance if a user chose "Central" with value "CT" I have no way of knowing if that is -0600, and neither does the Now button.

The library would have to be updated with a mapping of timezones, which would bloat the library. The other option would be to add another key to the option objects, so it would be like:

$('#timezone_example_3').datetimepicker({
    timeFormat: 'HH:mm z',
    timezone: 'MT',
    timezoneList: [ 
            { value: -500, format: 'ET', label: 'Eastern'}, 
            { value: -600, format: 'CT', label: 'Central' }, 
            { value: -700, format: 'MT', label: 'Mountain' }, 
            { value: -800, format: 'PC', label: 'Pacific' } 
        ]
});

This way if there is a format option that will be the content used for formatting, the value option would be the one used for setting the Date object.

This might cure the problem, but I can't say that I have time right now to add this feature in and properly test it. If anyone feels adventurous I would gladly review it and merge it if it looks well done.

[qingfx]

Not sure if this is still on the table, but if it does, I'm sending out PR#870 which might help resolve the issue a bit.

[h0jeZvgoxFepBQ2C]

It would be really great to add something like this... The bloat of 100 lines code is also negligible imo..