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. On Monday, September 10, 2012 6:47:50 PM UTC-4, Thomas Broyer wrote: > > > > 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. > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/S-yYZ9Y6TocJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
