Date and time pickers in any timezone

[Andy]

I recently needed to write a time picker and have made it available as part of gwt-traction, the library of gwt widgets and utilities that we've made open source. It includes and auto-sizing textarea and some other goodies.

I have a blog entry about it here: Creating GWT Date / Time Pickers That Work in Any Time Zone

It was a bit frustrating to get the timezone issues right and I hope other people will benefit from it.

Cheers,

Andy

[Andrei]

Andy,

Great post. I just finished my own implementation of the same controls, and I followed the same logic with one exception.

You say that your server knows a user's time zone. How? A user may travel and access your site from a different computer set to a different time zone. So, what happens when a user has time zone A stored in his profile, but he accesses your site from time zone B?

I decided to implement a proper TimeZone object on the client, which allows me to show dates and times (and to take dates and times) in any time zone a user chooses, regardless on the browser time zone.

I'd appreciate your thoughts.

Andrei

[Andy]

In our application, TimeZone is a user preference. Regardless of where they are in the world and how their computer and browser are configured, our application renders using their preference.

Basically, "time zone A" as you call it is authoritative and "time zone B" is ignored. Our date and time controls, called UTCDateBox and UTCTimeBox, are written to operate independently of the browser's TimeZone.

For example, suppose a user is editing an event taking place at 7pm Sept 10th EDT (about 30 minutes from now as I type this). If their user preference TimeZone is EDT, the server will tell the controls to render "7:00 PM" and "Sept 10th, 2012". If the user preference TimeZone is JST, the server will tell the controls to render "8:00 AM" and "Sept 11, 2012". The controls themselves don't care about TimeZone. When the values come back to the server, the proper Java Date will be created that corresponds to the proper time using the values from the controls with the user's preferred TimeZone.

If that doesn't make sense, I'm happy to clarify further.

-Andy

[Thomas Broyer]

On Tuesday, September 11, 2012 12:36:33 AM UTC+2, Andy wrote:

In our application, TimeZone is a user preference. Regardless of where they are in the world and how their computer and browser are configured, our application renders using their preference.

Basically, "time zone A" as you call it is authoritative and "time zone B" is ignored. Our date and time controls, called UTCDateBox and UTCTimeBox, are written to operate independently of the browser's TimeZone.

For example, suppose a user is editing an event taking place at 7pm Sept 10th EDT (about 30 minutes from now as I type this). If their user preference TimeZone is EDT, the server will tell the controls to render "7:00 PM" and "Sept 10th, 2012". If the user preference TimeZone is JST, the server will tell the controls to render "8:00 AM" and "Sept 11, 2012". The controls themselves don't care about TimeZone. When the values come back to the server, the proper Java Date will be created that corresponds to the proper time using the values from the controls with the user's preferred TimeZone.

UTCDateBox/UTCTimeBox names are misleading.

To reuse the JodaTime (and JSR 310) vocabulary, what you're editing are "local" dates and times (i.e. YMDHMS, not an instant in time), and the server then associate the value back with a timezone to map it to an Instant.

That being said, I think you should be able to do it with the standard GWT DateBox, providing a formatter that uses the DateTimeFormat overloads that take a TimeZone.

[Andy]

I called it UTCDateBox because it always returns midnight in UTC on the date selected, independent of the TimeZone in which it was selected. To me, "local" date would suggest something in my local TimeZone and thus be different depending on how my computer/browser is configured or something lacking TimeZone information, but maybe I should read JSR 310 again.

In other words, you can normalize date editing by ignoring the TimeZone or by hardening the TimeZone. I chose to harden the TimeZone to UTC since the GWT DateBox that I wrap uses Date objects.

As I mentioned in my blog post, originally the UTCTimeBox was intended to return a value combined with the UTCDateBox (and always choose a time in UTC), but that proved impossible with the limited amount of TimeZone data available in the browser. Maybe UTCDateBox and LocalTimeBox would be better names.

[Andy]

There is another point that I meant to make last night. You suggested providing a formatter that uses the DateTimeFormat overloads that take a TimeZone. There is a format(Date,TimeZone) but there isn't a parse(String,TimeZone).

I considered appending a timezone to the String in DateBox.Format.parse, e.g. convert "Sept 10, 2012" to "Sept 10, 2012 GMT" and use a different DateTimeFormat that includes TimeZone, but I prefer the approach that I decided to take.

I also prefer dealing with the value as a Long instead of Date so I wrapped it in a Composite instead of subclassing the DateBox.

I think you'll agree that this implementation is pretty minimal and accomplishes the goal of normalizing date selection. As a bonus, it uses deferred binding to use input type=date for iOS.

Cheers,

Andy

On Monday, September 10, 2012 6:47:50 PM UTC-4, Thomas Broyer wrote:

[Andrei]

You don't need a TimeZone for parsing dates, as you observed in your post. I also had to implement my own box for parsing time, because I want my users to be able to enter time in any format they like (2pm, 2:00 PM, 2:00p, 14:00). Then I adjust the raw time (in milliseconds) using time zone's offset. And I do store all dates and times as Longs.

Basically, this is the same idea, but adjustments are made on the client side. I like your approach, though.

[Andy]

My understanding is that you can do this on the client side if you only need to edit in the timezone of the browser. The problem I had was that my users have a timezone preference that can be different than the browser and the browser doesn't provide access to every timezone. Because the timezone offset varies based on the Date and daylight savings on that Date (e.g. EDT -0400 vs EST -0500), I wasn't able to ensure that I was using the right offset for a given Date in the user's preferred timezone.

If you dig through the implementation of the gwt DateTimeFormat, emul Date, JsDate, etc. Date.getTimezoneOffset is provided by the browser in the timezone of the browser. There's no way to ask for the timezone offset of a date in an arbitrary timezone. If I missed something, I'd love to be corrected.

[Andrei]

I am not using browser's time zone and its offset - it would not work, as you correctly stated. I am using GWT's TimeZone object and its offset. I build this TimeZone object using the time zone ID which a user specified in his preferences. This requires me to pass the correct JSON string from a server to the client, which is a drawback in my implementation (client-side only) compared to yours (server-side adjustments).

I am trying to think of a drawback in your implementation, but so far nothing comes to mind :), apart from a minor inconvenience that you have to reload data if a user changed his preference.

[Andy]

Got it. I considered that approach as well, but it seemed a bit more complicated. Where are you getting the JSON data to present to the client?

[Andrei]

GWT has a file with JSON strings for all time zones they support (more than enough). I copied it to my server resources.

[Andy]

Got it. I saw that file -- user/src/com/google/gwt/i18n/client/constants/TimeZoneConstants.properties -- and wasn't sure if that was the approach you were taking. Thanks.