BUGFIX timeZoneString UTC & UTC+5.5

[Zauberfisch]

timeZoneString returns '+0100' for UTC+1, but returned just '+' for UTC+0 when in fact it should return '+0000'
And returns a fully incorrect string for timezone offsets like UTC+5.5 or UTC+x.75

timeZoneString now returns a consistent and correct string for UTC+x.25 UTC+x.50 UTC+x.75 and UTC+0

UPDATE: renamed timeZoneString to make it public accessable

[Zauberfisch]

UPDATE: changed the pull request to a fix for both, UTC+0 and UTC+5.5

[Zauberfisch]

hmmm, I just figured out thats not that useful actually, because it just gets the offset of a date object, which only returns the browsers timezone, never the timezone I actually want ..

[Zauberfisch]

what I actually need is the parseDateTimeInternal to be public, may I rename it to $.timepicker._parseDateTime() or so?

[trentrichardson]

Hey Zauberfisch, thanks for more code.

I haven't had a chance to test myself, but does this handle the different values for timezone for example like "CST" or "EST" (US central and eastern time) which are non-numeric? A couple weeks ago I added an example of this in the index.html page in the dev repo. There is a timezone example with letter codes and custom lists.

Also for _parseDateTimeInternal there already is a $.datepicker.parseTime and $.datepicker.parseDateTime, maybe those will work?

Again I really appreciate your help and contributions!

[Zauberfisch]

actually, the all the timeZoneString function does is take a date object and then return date.getTimezoneOffset() formatted better (+0100)
It however has not really anthing to do with a timezone shortcut or name.

But yes, it would be nice to make this datetime picker capable of handling actuall timezone names like CEST, Europe/Vienna and so on, but thats something for another ticket, and probably another developer, I don't have time for such a change, sorry.

About _parseDateTimeInternal:
_parseDateTimeInternal returns something completely different than $.datepicker.parseDateTime
$.datepicker.parseDateTime calls _parseDateTimeInternal and then creates a new Date object out of that.
Problem is that I need to access the timezone string (+0100) of a given date string ('01.02.1337 13:37 +0100') and I can only do that with _parseDateTimeInternal as far as I know

[trentrichardson]

Ok, just checking. I got the string timezone mostly working a few weeks ago but it could be improved. Just making sure these changes play nicely with that scenario. I appreciate all you have done, thank you!