I'm not sure how to so this -- my testing involved manually setting the machine's time zone. Ultimately the bug is in the fact that the native Javascript Date functions deal with the missing hour differently that Java's Date class, and I don't know that I can coerce the Javascript functions into doing this specific behavior except by altering the OS environment.
Also, this particular bug should only manifest when moving the clock ahead. When going in the other direction, there is no missing hour, instead there is a duplicated hour. While that may lead to other problems, it won't cause a wrong date to be inferred. There's a theoretical possibility that some location could advance their clock by something other than one hour. I'm not sure what to do about that, but I don't think there is anywhere in the world that does this at the moment. Dan On Fri, Oct 30, 2009 at 12:41 PM, <[email protected]> wrote: > We should have unit tests for all of these cases, testing DST going in > both directions (spring and fall). > > LGTM pending unit tests > > > http://gwt-code-reviews.appspot.com/90802 > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
