If you time zone is fixed, why would you use a string to represent date/time? You can send a standard Java Date object to the client. If you want, you can even store all dates and times as Longs and pass Longs only. You also send the GWT's TimeZone Json string for your time zone (once per session). You can find it in the GWT - there is a file with strings for all time zones.
On a client you use DateTimeFormat with many predefined formats to display whatever you need: full date, month and date, date and time, etc. Just remember to create TimeZone object from this Json string 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 that Json string) and locales. You only pass simple Date or Long objects.
Andrei, it's a little too late to change to Date or Long. All our DTOs passed to client are String and have all info in ISO8601. The exception being a day which is yyyy-MM-dd format. Thinking on this, it may be that that is a problem b/c when DateTImeFormat.parse is called it parses using client's TZ not "market time" as I mentioned earlier. I guess I'm missing something here.
Also, if you look closely at test, we map Date (hour) to hour labels. 01 is 1:00am. 24 is midnight of next day. This is not such a simple effort when you take into account transition days.
You can specify a time zone in your string (in GMT+- format). Parser will take it into account when creating a Date object.
I might try that. However, doesn't the offset from GMT differ when day is a transition day, e.g., Nov-04-2012 and Mar-10-2013.
Also, you can create your custom parser since you know (and control) the format of the string, but appending a time zone to your strings may be enough to make a standard GWT parser usable for your use case.