
Java SE 8 Date and Time - javinpaul
http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html
======
apaprocki
Is there any talk in the Java world of decoupling the runtime from the tzdata
distribution? AFAIK, it is still coupled together and requires a tool to
update the data files or you have to apply JRE updates (which must be
published in time).

The tzdata updates usually 10+ times a year and a company actually operating
in most of those zones needs to have a straightforward way to push out updates
not only across all production systems, but across all production _languages_.
This usually makes solutions that "transpile" the binary data into native
source or otherwise embed the data into resources somewhere much more
operationally expensive. Native solutions (e.g., pytz in Python) that can be
pointed to an directory to pick up the tzdata binary files are a good middle-
ground, as it decouples the logic from the data.

Operationally, you need to be able to deploy the updates very quickly. Every
year there are data updates that occur a few days before the DST change. If
you have a lengthy dev/beta/prod rollout process to a very large number of
machines, this can bite you. Just this week, Chile and Turkey are making
changes, so prepare to update :)

~~~
rlmw
The distribution of new Java versions is already decoupled from tzdata
updates.

If you want to update your tzdata then you should use the tzupdater tool that
is shipped with Java. This has been updated to support JSR-310. If you want to
perform the updates then this is just a commandline tool and can be integrated
into chef/puppet etc. as needed.

There was discussion during the development of JSR-310 about the inclusion of
Java library methods to update a running JVM. There are a load of "not obvious
to a developer" things that happen if you do this and it was decided the
technical complexity and potential confusion outweighed the benefit of
implementing it.

~~~
apaprocki
That's what I was referring to, though, as being operationally expensive. I
need to ensure we're using up-to-date tzdata, but there could be multiple
different runtimes running on hosts in locations I'm not aware of.

All I really wanted to say is that I want to be able to do a file drop of all
of the binary data in a well-known location on all hosts and have all of the
relevant languages / runtimes point to those files without running any
additional tools, etc. Complexity starts multiplying once you add these
external processes because of additional failure modes -- e.g., someone can
run the tool manually and make things out of sync, no tools to monitor that
things do stay in sync, handling backout of bad deployed data, installing a
new not-yet-updated JRE version to a machine.

------
beachwood23
If Java Date was so broken before this, what have businesses been using the
past few years? The article mentioned Joda-Date, but I'm curious if companies
have used other solutions, or even built in-house solutions.

~~~
kasey_junk
The joda libraries are the de-facto standard. I have seen custom solutions but
usually those are for lower than millisecond resolution.

~~~
greatsuccess
Actually it looks like Java 8 will improve on Joda-Time, its far from perfect.

------
fenesiistvan
Good, but we expect much more from a major java release (i know that there are
also some other improvements, but not too much). I would even welcome an
applet come-back (with some fresh ideas and some strong answers for the
browser security related issues, keeping the old good java stack, not just the
name like in case of JavaFX)

~~~
brazzy
> Good, but we expect much more from a major java release (i know that there
> are also some other improvements, but not too much).

If the introduction of lambdas and streams is not enough for you, nothing will
be.

~~~
fenesiistvan
As justingregoryuk mentioned, i am thinking more on java as the platform. Why
they (Oracle) don't come out with some innovation in this field? There are
endless possibilities and they are sleeping.

------
al2o3cr
"Time zones, which disambiguate the contexts of different observers, are put
to one side here; you should use these local classes when you don’t need that
context. A desktop JavaFX application might be one of those times."

WAT. Even if you assume that your user has exactly one TZ, how does this work
with DST / summer time?

~~~
kinofcain
Agreed, it's unclear from these examples if time-zone-less local times don't
know about dst rules, or if they are backed by the user's timezone under the
hood. Either way, calling DateTimes without timezone data LocalTime seems like
a terrible idea, as "local" time is a very overloaded term.

It's often necessary in calendaring to describe a date time not as a point in
time, but as a user-relative point in time (think holidays or birthdays).
Android has support for "all day" dates in it's Time class, which is a step
forward, but doesn't handle things like an alarm that should wake a traveller
up at 6am tomorrow regardless of what time zone they have flown to. It's not
clear that this new LocalTime is going to be a sufficient container for these,
what the iCal RFC calls "floating times".

~~~
rlmw
Hi - just to be clear up front I co-authored the article. Thanks for raising
this very valid point of confusion.

Let's address the issues one at a time.

1) What's the point in Local _?

The goal is to give people the option to ignore the complexity involved with
time zone rules. People are intuitively familiar with what these things mean.
If you have a calendar on your wall above your desk: that's a LocalDate. If
you have a clock on the wall: that's LocalTime. With respect to how they work
in the presence of DST, they will automatically change time. For many use
cases LocalDate and LocalTime is entirely suitable and people shouldn't be
forced to put up with the unbearable complexity of timezones when they don't
need to.

2) Why are they called Local_?

As I mentioned above they represent the perspective of a clock on your wall or
a calendar on your desk. They are local in this sense. I appreciate that these
things might be a bit weird when you first get used to them and there was some
discussion about renaming the classes during development. It was concluded
that there were no better class names at the time. Furthermore if you looks at
ISO 8601 [0] which is the most relevant standard to this API the same concept
is also referred to as Local, Jodatime also uses the term Local.

3) Birthdays, Holidays and relative points in time

If you want to handle something like a birthday then there is a "MonthDay"
class in JSR-310 which is designed for this exact purpose. It is a composite
class of a month and a day and has an API consistent with the other classes in
310. If you want to handle 'relative' points in time then you might want to
consider using the Duration or Period classes.

Hope that helps!

[0]
[http://en.wikipedia.org/wiki/ISO_8601](http://en.wikipedia.org/wiki/ISO_8601)

~~~
kinofcain
Thanks, that does help.

RFC 2445 refers to those date times at "floating", which I always preferred,
since "local" is overloaded and makes it difficult to talk about:

[http://www.ietf.org/rfc/rfc2445.txt](http://www.ietf.org/rfc/rfc2445.txt)

"floating" is a weird term, and I hate making words up, but at least it
doesn't get confused in conversation with a time-zone-decorated timestamp that
just happens to be in the user's local timezone.

But as long as it's possible to do what we need, which is sounds like it is,
then that's what matters.

Thanks for the writeup.

EDIT: Regarding "Birthdays, Holidays and relative points in time",

MonthDay is not sufficient to describe all of the types of "floating" times,
the canonical example given in RFC 2445 is of a user who wishes to appear
unavailable at lunch every day, regardless of what time zone they are in.
That's a more granular resolution than a day, but it's the same concept: an
arbitrary precision, time-zone-less date that has no equivalent UTC start time
until it is "observed".

------
nogridbag
For those anticipating upgrading to Java 8 but would like to start using the
new API now with JDK7, you might want to look at using the threeten backport
so you can transition to the new Java 8 date API easily in the future.

[http://www.threeten.org/](http://www.threeten.org/)

[https://github.com/ThreeTen/threetenbp](https://github.com/ThreeTen/threetenbp)

------
bluedevil2k
java.util.Date wasn't broken per se, since people have been using it since
Java first came out. It's just not pleasant to work with, the naming
conventions are wrong, it's short-sighted in terms of international dates,
etc. Classic example of what's wrong with the old methods - the dates are
0-indexed.

~~~
mbell
Here is one example of why I think Date is broken:

For quite awhile (maybe still?) calling `new Date()` made a synchronized call
to a static method to try and figure out the default timezone. That created
nasty lock contention in multithreaded code, nuking performance. Of course
there is no way to create a new Date with a particular time zone. The other
option was using the Calendar class since you could pass in a time zone, but a
Calendar takes ~20 times more memory and is slow as hell to create. This meant
you couldn't do something as simple as creating new Date classes with
reasonable performance.

------
bane
I've recently been sitting down and relearning Java. Not good enough to be
idiomatic in the language, but whatever. One of the first things I banged into
was the unbelievably bad date/time libraries that are built in. After banging
my head for a couple hours trying to figure out the magical combination of
classes I needed to assemble to get a date formatter to work, I just ended up
rolling my own in half an hour.

I'm frequently surprised at the really rough and inconvenient bits in Java.
Weird inconsistencies in the libraries, or not having a really convenient set
of file read/write methods without having to cobble together bits and pieces
of an I/O system to get a directory listing or read in a file or whatever, or
how variable performance is between two similar looking pieces of code (if you
haven't done lots of benchmarking on Java standard library containers, I urge
you to do it, and make careful selection of containers based on that, it's
frequently surprising how different otherwise identical looking code runs).

Considering there are what, 3 complete GUI toolkits built in, why isn't there
a built in CSV parsing library, or a "read file to string" static method
somewhere? Why do I have to put so much effort into basic tasks? It's such a
weird and uneven and sloppy feeling thing.

There's all these weird aggregated different ways to do the same thing, but
each built to fix some problem with some older solution, but the older broken
ways were never really deprecated out for compatibility. Unless you run across
some guide that says explicitly "use this instead of this because of
<reasons>" you might never know the newer version exists. Yet the new releases
includes so much compatibility breaking new syntax changes that it doesn't
practically matter.

There's bits and pieces of related but complete solutions piled all over the
library as well. e.g. Regex bits are in String, java.util.regex.* (Pattern and
Matcher) and probably elsewhere...and don't get me started if you're moving
back and forth between arrays and the various containers that make arrays more
usable, and then all the utilities to help with that which are scattered all
over the place. I spend half my time writing code to abstract all that
nonsense away so I can write the main code logic in peace.

And then over the years the concepts about how to design an API have changed
or something, because you can feel different stylistic concepts in different
places. Here you instantiate an object, then set it up, then build another
object of this type to catch the results and do some other magic. Here you
instantiate the object with all the important bits and manipulate the object
with local methods. It's like each class requires it's own style guide. I can
understand that with 3rd party work, but it doesn't make sense with the
batteries that come with the language to be so uneven.

It was probably 10 years ago that I last tried Java, and it sucked back then,
with all the verbosity etc. But with modern IDE support I actually kind of
like the flow and style of it to some extent. It's a beautifully simple syntax
to use at its core. But then again I don't care about all the FactoryFactory
nonsense. And I'm avoiding lots of the new stuff that doesn't really fit into
the language.

I've actually started to become convinced that it's getting to the point that
Java 10 or whatever should be a single minded house cleaning. Jettison all the
broken old shit, clean up the style and usage, build decent syntax into the
language for doing common tasks so the coder doesn't have to boilerplate
themselves to death. Take 5 years to do it, the enterprise will survive that
long.

 _edit_ I wonder if the idea of an "API editor" to vet the interfaces for
consistency and style in these large standard libraries makes sense?

~~~
mseebach
The only way to think about Java and not go insane is to forget about pretty
much the entire built-in standard library and instead go use the extremely
solid 3rd party libraries. If I don't have JodaTime, Apache Commons and Google
Guava on my classpath, I feel like my hands are tied.

~~~
twic
I think that's a bit strong. There are bits of the standard library that are
fine - collections, concurrency, and anything else designed by Doug Lea. I
even get on fine with IO and most of networking. Sure, Guava adds a lot of
really nice stuff to collections, but it adds rather than replaces.

Then there are bits which should be avoided at all costs. Date and time is
one. All the GUI libraries are another. HTTP via URLConnection isn't terrible,
but people mostly use Apache HttpClient instead. NIO is a mixed bag, with some
really good bits, and some complexity whose necessity escapes me (particularly
since it can be hidden by XNIO without losing anything).

It is a real shame that there is this patchiness. I would love to claim that
all the rough code is from the pre-1.2 era, but i would be lying. Particularly
if you look beyond the JDK and into the enterprise libraries, there have been
some real shitshows given official imprimatur (i remember Java Advanced
Imaging being particularly horrifying).

~~~
skyebook
JAI was real bad.. JMF (Java Media Framework) was another one, which for a
while had the unfortunate distinction of being the only reliable way of
playing video on top of being poorly documented and turning into abandonware.

------
moron4hire
20 years to finally get this right. TWENTY YEARS, MAN!

~~~
melling
Java startup time will hopefully be fixed in Java 9. That also has been
eagerly anticipated for quite some time.

[http://mreinhold.org/blog/late-for-the-train](http://mreinhold.org/blog/late-
for-the-train)

~~~
twic
I initially parsed this as suggesting that a JVM took 20 years to start up,
and thought "Come on, man, with the right flags it's no more than 12 ...".

------
gldalmaso
>> _The new API avoids this issue by ensuring that all its core classes are
immutable and represent well-defined values._

Is there any kind of talk of adding immutability to the core language? "final"
keyword doesn't really cut it for objects and immutabililty by convention also
is not easy to enforce on large teams.

~~~
rlmw
There has been a lot of discussion on this kind of thing. One of the proposals
for value types is to have them be immutable.

As to what to do in the meantime - I would suggest that you use either
findbugs' immutability detection or Graham Allen's Mutability Detector:
[https://github.com/MutabilityDetector/MutabilityDetector](https://github.com/MutabilityDetector/MutabilityDetector).
Findbugs picks up an @Immutable annotation and checks whether this is the
case, whilst Mutability Detector allows you to assert that classes are
immutable as part of your unit tests.

I appreciate its not as good as language support, but it is better than
relying on an unchecked convention.

