On Wednesday, June 5, 2019 at 11:01:59 AM UTC+2, Jens wrote: > > I looked at the file and the GWT code using it and the format seems pretty > clear to me. Writing a new tool looks pretty simple, we just have to decide > which implementation strategy to choose. > > > 1.) use JDK java.time package to read the tzdata information packaged with > Java. > > Given that JDK is now released every 6 month, this might also be a nice > minimum time frame for possibly automated GWT patch releases with new > tzdata. >
Fwiw, the tzdata on Linux (and possibly any non-Windows OS) is generally updated independently from the JDK, and is shared between all JDK versions on the machine. > Otherwise if we want to update tzdata in GWT outside of JDK releases, the > process is a little more complex because we first have to generate a > tzdb.dat file to update a JDK installation. To generate that file, we would > also need to use the source from the JDK version we use to execute the GWT > tool that generates the GWT json files because the tzdb.dat file format > might change between JDK versions. > > > 2.) Use Joda Time and their api to read the tzdata information > > You would need to checkout Joda Time sources, put the new tzdata files > into a special package and then build Joda Time. A tool would then depend > on that custom build Joda Time and use the Joda Time API to produces the > GWT JSON files. > There's also ICU4J, which we already use for other i18n related code generation. Its API is similar to the JDK one, but it comes with its own tzdata bundle (afaict). Personally I kind of like option 1.) because we could then align automated > GWT releases to JDK releases, e.g. one month after JDK release, and the GWT > tool could just use standard JDK API without any dependencies. > The upside of using the JDK is that it uses the "system" (though java-specific) tzdata (at least on Linux, at least with OpenJDK packaged by the distros), so it's almost guaranteed to be up-to-date. The downside is that is machine/environment-dependent. The upside of using ICU4J (or possibly JodaTime) is that it's not system/environment dependent. The downside is that it requires updating ICU4J, but that's probably a good idea anyway (but it'd be easier to do it within a separate project using "managed dependencies" –Maven, Gradle, etc.–; we probably wouldn't want to upload every new version of ICU4J to the "tools" repository; this could possibly be done in the new gwt-i18n project for example, with a special task to generate the files needed for GWT2). I think using the JDK will be "good enough" (given the status quo of having outdated data that we don't even know how to update), and we could still migrate to ICU4J later if we feel it's better. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/31eeb824-4f40-4fe0-8135-e21f5988166b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
