[tz] [english 100%] Re: Joda-Time, Time4J, and Java SE 8

[Meno Hochschild]

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 &ndash;
> 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 &ndash; 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 at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20160708/4b5177df/attachment.html>