I think we should not loose the main point out of focus which is to mention time libraries which make any usage of tz-repository of IANA. So we have at least: old Java pre 8, Java-8, Joda-Time and my lib Time4J (my proposal was to list it in tzlink as separate entry within the section "Other tz compilers" because it does have an*independent tz compiler* - like the standard apis and the much more known library Joda-Time which exists since 2002). And this relation to IANA-zone data is the main purpose of tzlink. What we should not do is going into too many details what the libs are where are difference where are common interfaces history etc. Interested people can simply follow the links given and form their own opinion, gathering more infos etc. I also suggest to leave out entries or details or opinions which have nothing to do with the purpose of tzlink-file. Just limiting the entries to the facts related to tz-data is fine enough. Kind regards Meno Am 08.07.2016 um 13:34 schrieb Stephen Colebourne:

For many years, Joda-Time has been the de facto default library for date and time in Java. In the last few years two things have happened. 1) Time4J came out (no idea how widely used it is) 2) Java 8 was enhanced with a new date/time API "inspired by" Joda-Time (because I wrote both)

The Java 8 code is also supplemented by ThreeTen-Extra (which includes leap second support). http://www.threeten.org/threeten-extra/

The Java 8 code has been backported to Java 6 and 7 (but this is only for specialised use cases). http://www.threeten.org/threetenbp/

Joda-Time will over time be less and less used as people migrate to Java 8, supported by ThreeTen-Extra if needed.

I would recommend keeping the Time4J line in tzlink separate from the Joda-Time/Java 8 line, as while Joda-Time and Java 8 have a lot in common, Time4J doesn't have any history in common at all. It also allows you to simplify the license part, which is complex as written.

<li><a href="https://github.com/MenoData/Time4J/">Time4J – Advanced date, time and interval library for Java</a> contains a class <code>net.time4j.tool.TimezoneRepositoryCompiler</code> that compiles <code><abbr>tz</abbr></code> source into a binary format. Time4J is available under the <a href="http://www.gnu.org/copyleft/lesser.html"><abbr>GNU</abbr> Lesser General Public License (<abbr title="Lesser General Public License">LGPL</abbr>)</a>.

<li><a href="http://www.joda.org/joda-time/">Joda-Time – Java date and time <abbr>API</abbr></a> contains a class <code>org.joda.time.tz.ZoneInfoCompiler</code> <code><abbr>tz</abbr></code> source into a binary format. Joda-Time is available under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License v2</a>. From Java 8 onwards, users are recommended to migrate to the new built-in <a href="http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html">Java SE 8 <code>java.time</code> API</a> API that was inspired by Joda-Time, supplemented by <a href="http://www.threeten.org/threeten-extra/">ThreeTen-Extra</a> if necessary.

Stephen

On 8 July 2016 at 11:45, Paul Eggert <eggert@cs.ucla.edu> wrote:

...

On 07/08/2016 06:23 AM, Meno Hochschild wrote:

...

it is not quite correct to say that Joda-Times "functionality is a standard part of Java 8". It has rather inspired the development of java.time-package in Java-8.

Thanks for the correction. Sorry, I don't know Joda-Time vs Java SE 8 vs Time4J well.

I'm trying to future-proof tz-link.htm. As I understand it from the Joda-Time web page, Joda-Time-using apps are expected to migrate to the Java SE 8 API, so future readers of tz-link.htm will mostly be using the Java API, with more-specialized uses (leap seconds? sorry, don't know the details) possibly using Time4J, and Joda-Time being a historical footnote.

I installed the attached further patch into the experimental tz version on GitHub; I hope it addresses this point well enough. I'll CC: Stephen Colebourne to give him a heads-up, as I do want tz-link.htm to be accurate.

Looks reasonable to me. thanks Stephen On 19 July 2016 at 13:39, Paul Eggert <eggert@cs.ucla.edu> wrote:

On 07/08/2016 01:34 PM, Stephen Colebourne wrote:

...

I would recommend keeping the Time4J line in tzlink separate from the Joda-Time/Java 8 line, as while Joda-Time and Java 8 have a lot in common, Time4J doesn't have any history in common at all. It also allows you to simplify the license part, which is complex as written.

Thanks, I tried to take all that into account by installing the attached patch. This also adds a subsection for Java to try to organize things a bit better (much as we've already done for JavaScript).