Open niloc132 opened 2 years ago
Review pending https://gwt-review.googlesource.com/c/gwt/+/23761, but this is waiting on two other patches to be able to land.
The fix I proposed doesn't work, I incorrectly verified that modern browsers are behaving by only testing one of the two cased documented as "some browsers have this behavior". I'll try to either simplify the fix and see if there are any other benefits to gain here.
GWT version: 2.8+ (but goes back to the early days of gwt) Browser (with version): any Operating System: any
Description
GWT's java.util.Date emulation has a check in the method
fixDaylightSavings
to make sure its dates are consistent with the JVM: https://github.com/gwtproject/gwt/blob/3dc21707a4b6aa1af7139986fa7e3b9c213fee05/user/super/com/google/gwt/emul/java/util/Date.java#L232-L299This is less applicable today than it used to be: IE8 returns 1 (workaround required) IE9 returns 1 (workaround required) IE10 returns 3 (expected) IE11 returns 3 (expected) Edge returns 3 (expected) Chrome 93 returns 3 (expected) Firefox 91 returns 3 (expected)
GWT's provided DateTimeFormat ends up calling this several times in the course of parsing a string and writing it to a Date object - for example, this is called by setDate/setHours/setMinutes/setSeconds, all of which are called sequentially in the internal DateRecord type that helps with parsing (and setDate is called twice, setMonth once before this snippet): https://github.com/gwtproject/gwt/blob/3dc21707a4b6aa1af7139986fa7e3b9c213fee05/user/src/com/google/gwt/i18n/shared/impl/DateRecord.java#L142-L150
Given that two browsers GWT 2 still supports require this branch, we can't outright remove it (until we remove support for those browsers...), but perhaps a workaround could be added where we detect "old enough" / "new enough" browsers and selectively apply the check.
Steps to reproduce
Visit https://hollow.colinalworth.com/date.html from a computer in a US time zone which used daylight saving time in 2009 and check what number is written to the page - if 3, the browser in use behaves the same as the JVM, if 1, the browser will require a workaround. This page runs the following JS, as noted in the Date implementation above:
new Date(2009, 2, 8, 2, 0, 0).getHours()
.Here is a small sample app that demonstrates the issue in either GWT2 or J2CL:
HTML file to run it with:
Testing with 100,000 dates to parse, on my computer this takes ~1.3s in either gwt2 or j2cl+closure. Here's the performance data from chrome's dev tools from the GWT2 build of this (using style=PRETTY):
Same details from J2CL+closure (though using ADVANCED compile, and I'm not sure how to keep names unobfuscated in a production build, but the structure should be clear from the above images):