Opened 10 years ago

Closed 5 years ago

#12021 closed defect (patchwelcome)

TimeTextBox does not work correctly in some timezones

Reported by: jords Owned by:
Priority: high Milestone: 1.13
Component: Dijit - Form Version: 1.5
Keywords: date, TimeTextBox Cc:
Blocked By: Blocking:


I have been dealing with an issue where the timetextbox will return times with the wrong timezone. This occurs when I am using the Pacific/Auckland? (currently GMT+1300) timezone; it does not occur with any other timezone I have tried.

The issue is that selected times before 12pm are returned as GMT+1300, while times after 12pm are returned as GMT+1200. I then noticed that this seems to be a result of the behavior of the browser Date object, and not strictly a bug in Dojo.

Here is a log from firebug, the issue is identical in chrome also: Time before 12pm, returning GMT+1300:

new Date(1970,0,1,5,2)

Thu Jan 01 1970 05:02:00 GMT+1300 (NZST) {} Try a time after (or exactly) 12pm, returns GMT+1200:

new Date(1970,0,1,12,2)

Thu Jan 01 1970 12:02:00 GMT+1200 (NZST) {}

When using February 2nd, all is well:

new Date(1970,0,2,15,2)

Fri Jan 02 1970 15:02:00 GMT+1200 (NZST) {}

new Date(1970,0,2,5,2)

Fri Jan 02 1970 05:02:00 GMT+1200 (NZST) {}

I'm not sure what the best way to resolve this would be - It should be possible to use February 2nd instead, but this might still not always be correct, although it should be consistent between morning and afternoon.

Change History (12)

comment:1 Changed 10 years ago by jords

I have now done some more testing. This issue is present on my Linux (Ubuntu 10.10) machine, but there is no issue when running Windows XP. This would appear to be an issue much deeper than even the web browser.

comment:2 Changed 10 years ago by bill

For 2.0 we'll stop using the Date object altogether and just return a String. Not sure if this is worth fixing in the interim. Actually why are you even looking at the time zone rather than just the time itself?

comment:3 Changed 10 years ago by jords

I'm not looking at the timezone directly, but helpfully (mostly, but not in this case :) looks at the timezone and takes that into account when determining the number of hours between two dates.

If just a string is going to be returned, I guess I will need to go through another step then to get a date object I can use to calculate differences with? It is convenient to have a date object directly, aside from this issue

comment:4 Changed 9 years ago by bill

Milestone: tbd2.0

comment:5 Changed 9 years ago by bill

Component: DijitDijit - Form
Owner: set to Douglas Hays

comment:6 Changed 9 years ago by Douglas Hays

Resolution: wontfix
Status: newclosed

Fails on Mac OSX 10.6.8 as well on Chrome, but there's nothing that we're planning on doing to specifically fix this issue since it's not a Dojo problem. Changing to strings will fix this as a side-effect.

comment:7 Changed 9 years ago by bill

Resolution: wontfix
Status: closedreopened

As I said above, for 2.0 we'll stop using the Date object altogether and just return a String. Thus, this will be fixed then.

comment:9 Changed 6 years ago by bill

Status: reopenedopen

comment:10 Changed 5 years ago by bain

This bug still occurs in the digit TimeTextBox? example: Locale is en_GB.

comment:11 Changed 5 years ago by bill

Owner: Douglas Hays deleted
Status: openassigned

comment:12 Changed 5 years ago by dylan

Milestone: 2.01.12
Resolution: patchwelcome
Status: assignedclosed

Given that no one has shown interest in creating a patch in the past 4+ years, I'm closing this as patchwelcome.

Note: See TracTickets for help on using tickets.