GWT Date Handing ... has a client server time zone

Question

I read a lot of posts here: GWT date processing.

One, in particular, which pierced with me a cord, was this

Sending date and time zone from GAE server to GWT client

In any case, there is a need for a project that I am working on to show days, hours, minutes and intervals as labels in a grid. My team took an approach where all instances of the date and time are transmitted by the client from the server in String format in ISO8601 format. The server time zone must be respected by the client. The use case for biz is that all instances of the date and time are in the "market time", so that any browser that visits the application will see and work with the dates in the "time zone of the market", which occurs at GMT-05: 00 (if Summer Savings) or GMT-06: 00 (if standard time is used).

I posted the source on Github, here:

https://github.com/fastnsilver/gwt-datehandling-example

In particular,...

https://github.com/fastnsilver/gwt-datehandling-example/blob/master/src/main/java/me/fns/gwt/datehandling/client/util/CSTimeUtil.java

and GWTTestCase

https://github.com/fastnsilver/gwt-datehandling-example/blob/master/src/test/java/me/fns/gwt/datehandling/client/util/CSTimeUtilTestGwt.java

in the hope that someone can look at the utility (and test) that we use to process dates and help us understand what we don’t see.

EDIT The main problem is that CSTimeUtil#hoursInDay(Date) not computed correctly in Production mode for transition days. This method is used by other methods (for example, CSTimeUtil#dateToHour(Date) and CSTimeUtil#labelsForDay(Date) ).

I deployed our application with the current implementation of CSTimeUtil and it seems to work, but not quite. I am really confused by alternative test results when, for example, mvn gwt:test runs in GWT mode or in production mode on Windows, where the OS time zone is set to different time intervals other than US GMT-05:00 or GMT-06:00 .

Answer 1

Based on some hints of Andrew and some serious blood, sweat and tears, I realized this myself. I updated the code on Github, so if you're interested, take a look, please.

The basics:

• Make sure that all lines comply with the ISO8601 standard (without milliseconds) when sending from server to client and vice versa
• Use DateTimeFormat.getFormat("yyyy-MM-ddTHH:mm:ss.SZZZZ") to format and date parse
• Extract GMT-prefixed timezone information from java.util.Date to Market Time using DateTimeFormat(Date, TimeZone) , where TimeZone set to TimeZone.createTimeZone(TZ_CONSTANTS_INSTANCE.americaChicago()) and String timezone obtained from using TimeZone.getISOTimeZoneString(Date)
• The generation time, see generateDay(Date, int) or the clock generateHour(Date, int) , from the original date should have taken into account that the increment or decrement fist causes a change in the time zone offset if it occurs on the "transition day".

Answer 2

If the time zone is set, why use a string to represent a date / time? You can send a standard Java Date object to the client. If you want, you can even save all dates and times as Longs and skip Longs only. You also send a GWT TimeZone Json string for your time zone (once per session). You can find it in the GWT file with lines for all time zones.

On the client, you use DateTimeFormat with many predefined formats to display everything you need: full date, month and date, date and time, etc. Remember to create a TimeZone object from this Json line and use it in DateTimeFormat.getFormat (...). format (Date, TimeZone).

With this approach, you don’t have to worry about DST changes (they are encoded in this Json line) and locales. You only skip simple Date or Long objects.