Issue with com.google.gwt.i18n.client.TimeZone in GWT 2.11 for Africa/Cairo Time Zone about gwt HOT 4 OPEN

The last update for TimeZoneConstants.properties is 10 years ago and based on CLDR v25. So yes recent changes to daylight saving time information are missing in GWT.

Some work as been done by @vegegoku to create a J2CL compatible version of GWT i18n which uses a newer CLDR database but I don't know how the current state is.

Personally I also worked on i18n briefly and tried to write a tool that extracts the information from the JDK itself using code and reflection but if I remember correctly I discovered that the current abstraction that GWT uses in its TimeZoneConstants.properties file is not compatible to some newer DST rules.

The reason is that GWT stores DST transition points in hours since 01.01.1970 00:00:00 UTC and the code also just checks full hours to find the transition point. However there are DST rules with transition points on half hours or even some other weird fractions of an hour.

I think GWT needs to be changed to represent DST break points in minutes.

from gwt.

That is my recollection also - the "gwt-cldr-importer" has support for everything except timezones. It is my memory that there is a custom python script that Google can't or won't provide access to which historically updated these files.

At some point we had hoped to get more of those details from Google, but I think at this point we will need to start from scratch, probably outside of the gwt repo (unless we find we can be fully backwards compatible). I'm not aware of anyone working on anything related here at this point in time - so looking for a developer/sponsor to pick it up.

from gwt.

@niloc132 I just skimmed through my code and the JDK actually has an array of standard offsets per zone including an array with standard offset transition points. GWT currently only supports a single standard offset per zone. So this need to change as well because some zones have changed their standard offset over time.

from gwt.

Yes, I don't disagree with your assessment - if we can change it without breaking API, I'm all for it appearing in this repo, otherwise I'd tend towards breaking changes to user code appearing in the modularized repos (as they become available... closure-compiler is presenting deliberate barriers to localization in any form other than how it defines it).

from gwt.