Java SE 8 Date and Time

http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html

by javinpaul • 12 years ago

84 88 12 years ago

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• 12 years ago

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

greatsuccess• 12 years ago

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

smackfu• 12 years ago

A lot of people still use the built in Java stuff, they just don't enjoy it. Especially since a lot of code predates the existence of alternatives.

bhauer• 12 years ago

For most applications we build, if time is relevant for more than just incidental functionality, we will typically use Joda-Time. For simply incidental functionality (e.g., a few UI elements displaying the time), we'll use the standard API.

I've not seen any home-brew date APIs outside of a few bite-size pieces of functionality. For instance, we have one custom utility that takes two times and a granularity level to render a human-readable rendering such as "2 hours, 13 minutes ago."

gcv• 12 years ago

The ICU Java libraries, though annoying to use, provide interoperability with ICU C libraries. ICU has the only correct implementation of time zone support for C that I have found. Though it's been a while since I researched the issue, I think ICU did something with time zones better than Joda Time, also.

rlmw4• 12 years ago

Most people use the Jodatime library. JSR-310 is an extension of Stephen Colebourne's work on that library.

Obviously there are some people who use java.util.Date, but it is a real pain in the neck to use and is very commonly complained about.

ajanuary• 12 years ago

We use a mix of the built-in java dates and joda, depending on how old the code is.

We have our own time library for some domain specific time code, which internally uses joda to handle dates.

moron4hire2• 12 years ago

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

melling• 12 years ago

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

twic2• 12 years ago

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

viraptor• 12 years ago

And it will take quite some time to actually get deployed anywhere. JRE 6 is enough for everything we need to run, right? So why update it? :(

jfb• 12 years ago

19, you mean?

moron4hire2• 12 years ago

I used Java to calculate the time difference.

bluedevil2k• 12 years ago

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.

yonran• 12 years ago

The months and days of week are 0-indexed. The dates of month are 1-indexed. Same as javascriopt. You always have to be careful with this API, but it helps to remember that they return an index in an array for the items that have a name in English (“January” and “Sunday”).

mbell• 12 years ago

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.

al2o3cr• 12 years ago

"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?

kinofcain2• 12 years ago

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

nogridbag3• 12 years ago

The Local* classes are immutable and do not store a time zone internally. So for instance, you can use LocalDate as a floating date to represent things like a birth date.

They're similar to Joda's Local* classes but the API has been cleaned up and vastly improved. Gone are all of those ugly constructors. They've been replaced by elegant static factory methods:

LocalDate.now(newYorkZoneId)

LocalDate.of(2013, Month.JANUARY, 1)

rlmw4• 12 years ago

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

fenesiistvan2• 12 years ago

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• 12 years ago

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.

fenesiistvan2• 12 years ago

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.

justingregoryuk2• 12 years ago

Yes, they should push the platform not the language. There is still a very big potential in java. I am thinking about something like java se on ios. Or a new mobile platform based on java se. Or even better: a platform with html user interface and everything other java se. Firefox made it on javascript.

FreezerburnV• 12 years ago

There are projects that do something along the line of both of your suggestions. For iOS, there's a project called RoboVM. (it's still claimed to be alpha, but the game engine LibGDX uses it to deploy to iOS). For web, there's GWT, which allows you to develop web apps in Java and it compiles to HTML/CSS/JS (or something along that line, though I hear it's verbose. LibGDX/PlayN use it to deploy to the browser though)

pswenson2• 12 years ago

the answer to applet security problems is HTML5

apaprocki2• 12 years ago

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

rlmw4• 12 years ago

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.

apaprocki2• 12 years ago

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.

bane12• 12 years ago

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?

skocznymroczny• 12 years ago

In Java 7 you can use Files.readAllLines to read file to string, also there is a built-in CSV parsing library, it's called String.split() :)

bane12• 12 years ago

Files.readAllLines

Geez, I think I've already reimplemented that half a dozen times. Of course it would be buried in the Files class and not one of the 30 dozen buffer reader whatever classes I have to piece together.

String.split()

Yeah yeah, that's what all the Java books say ;)

nogridbag3• 12 years ago

String.split will work fine until you have data like this: Sarah Jones,Paul Williams,"Smith, John",Fred Johnson

It's best to use a library for this like SuperCSV: http://supercsv.sourceforge.net

Too• 12 years ago

yeah right.....and what's the XML parsing library called? java.util.regex? And the SQL parameterized query library? string.format?

herge• 12 years ago

I wonder how hard it would be to port all of the python standard library to java?

Sort of have python.csv.reader, python.csv.DictReader, etc, which all conform as java-ish as possible to http://docs.python.org/release/2.7.3/library/csv.html

bane12• 12 years ago

The problem of course is that it would probably be some external library like the apache commons stuff and never get integrated into the main library.

And there's still all the old poorly thought out junk still crufting up the standard library.

d07• 12 years ago

Regarding date and time stuff, everyone appears to use Joda-Time: http://www.joda.org/joda-time/

If you want inconsistent, .Net framework's collections and HTTP stuff was the worst for years. They added to the former and wrapped the latter but you still fall over crimes. Java collections and Servlet API are pretty good really in comparison.

It's not terrible really. Anything on that scale is inconsistent: python, ruby, .Net, C++.

The hard bit is learning where stuff is hidden. I'm currently doing that with Objective-C.

bane12• 12 years ago

Anything on that scale is inconsistent: python, ruby, .Net, C++.

Well, I wonder if this is necessarily inevitable. The Oxford English Dictionary is probably as large and complex as any of the above, but is remarkably consistent in style and tone. I'm a firm believer that good design extends to code (and coders are sadly not very good designers in general).

mseebach• 12 years ago

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.

saw-lau• 12 years ago

That's one of the main reasons I enjoy programming in C#/.NET. The fact that there are, as far as I'm concerned, a solid set of de facto libraries without having to hunt around for third-party ones somehow makes me feel warm and fuzzy.

bane12• 12 years ago

Thanks for the recommendations. I've been pretty happy with the little bit of Commons that I've been touching. Haven't tried Guava out yet...on the list.

twic2• 12 years ago

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

coldtea4• 12 years ago

With the exception of JodaTime, which is quite well designed, most of the third party libraries you mention or absolute shit. Apache Commons in particular is worse than ammateur hour work.

And while the quality of the standard SDK varies, most of it is very good, and there are stuff that's solid gold in there, like Nio and Concurrency libs.

agumonkey2• 12 years ago

Funny how in languages like python or clojure, the bazaar library eco system can be a fuzzy moving target daunting to control, while Java stdlib is on the other side of things, but too far, Guava, Apache Commons, Joda could have been made standard but it's not.

pswenson2• 12 years ago

I agree with you. yeah, there are some new APIs in nio Files that you weren't aware of. But now you have to know go to Files for the "Good API" instead of the old "File" API. Bow to the Gods of backwards compatibility!

The JDBC API is still beyond horrible (is there a decent 3rd party SQL API?). Checked Exceptions still survive. String still lacks many basic features.... and sadly as others have pointed out to get usable APIs you need Apache Commons.

I agree, Oracle needs to do some house cleaning. Some times it's ok to break things. Don't do it too often, but once every 10 years seems ok to me!

coldtea4• 12 years ago

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.

It's really not that difficult to assemble the combination of classes to get a formatter. There are problems with the API, but that's not one of them.

Plus, your hand rolled case probably misses hundrends of edge cases (I'm not exagerrating, date and time is one of the most difficult things to get right).

bane12• 12 years ago

It turns out certain subsets of things you need to do with Dates are pretty easy. In my case all I needed was to convert a date format to another. All I wanted was something like

   Date thing = new Date(someStringWithaDate,"MMM dd, yyyy");
   String newDateThing = thing.convertDateFormat("yyyy-mm-dd");

and be done with it. Or at worst

   Date thing = new Date(someStringWithaDate,"MMM dd, yyyy");
   Date newDateThing = thing.convertDateFormat("yyyy-mm-dd");
   String someStringWithaDateButFormattedLikeIWant = newDateThing.toString();

But the overwrought standard library just completely got in the way and I don't even remember how many lines of code and objects I ended up with just to do this before I said "fuck it" and did the equivalent of (with a some utilities to convert abreviated dates to numbers.

   String.replaceAll("([A-Z]{3}) (\d{2}), (\d{4})","$3-$2-$1");

Of course now I'm not getting whatever date validation the Date class might offer (if it does), and I ended up using a 50 cent solution when I really needed a $1.50 solution, but the standard library only offered an overpriced $20 way that I didn't need.

The end result is that we're all poorer for it.

krzyk• 12 years ago

As for the reading file into a string, there is almost somethig like that: http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files...

There is a method for reading a file into a list of lines (it is strange that they didn't include a method to read the lines into a single string).

cpprototypes• 12 years ago

The Java standard API has a lot of inconsistencies, but it would break too much code to remove old stuff. A simpler first step would be much more aggressive use of @Deprecated. There are entire packages in the standard API that should be deprecated. Most Java IDE strongly discourage using deprecated code. More use of @Deprecated would encourage future Java code to use more modern APIs.

nogridbag3• 12 years ago

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/

https://github.com/ThreeTen/threetenbp

gldalmaso• 12 years ago

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

rlmw4• 12 years ago

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

Java SE 8 Date and Time

Related Stories