If you're confident in the fix, Dan, instead of adding a test right now, please just add an issue instead to remind us to review in the future what kind of testing mechanism we would have needed to make a unit test easy to create for this case. I want to make sure we revisit this at some point to round out our testing story, even for hard things to test.
On Fri, Oct 30, 2009 at 1:23 PM, Daniel Rice (דניאל רייס) <[email protected]>wrote: > 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 -~----------~----~----~----~------~----~------~--~---
