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

[KausarJaid]

I am encountering an issue with the com.google.gwt.i18n.client.TimeZone class in version 2.11 of GWT. The problem lies in its handling of the Africa/Cairo time zone. It does not incorporate the recent daylight saving changes for this time zone.

After verification, I observed that the time zone for Africa/Cairo correctly reflects Eastern European Summer Time (EEST) and Eastern European Time (EET) for dates in 2004. However, for dates in 2024, it only shows EET and fails to account for daylight saving time changes.

I suspect that the TimeZoneConstants.properties file has not been updated to reflect these recent changes. Could you please let us know when this issue will be resolved?

Thank you for your attention to this matter.

[jnehlmeier]

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.

[niloc132]

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.

[jnehlmeier]

@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.

[niloc132]

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).