Date and Time in Java 8: Timezones

I doubt there's too much of a learning curve as the new API is pretty similar to Joda Time: http://blog.joda.org/2009/11/why-jsr-310-isn-joda-time_4941....

You'll also find that there will be a release of Jodatime after 310 is finalised that allows it to implement the top level interfaces defined by 310 - eg Temporal. This will allow the libraries to play nicely together and means you'll probably be able to write code like:

LocalDate date = LocalDate.from(someJodaTimeObject);

I've always wondered how the world in general can tolerate something like that. Here we are adding leap _seconds_ every year or so, and yet we're all totally fine with the same, indistinguishable hour repeating once a year.

Usually there is a separate timezone for daylight saving periods. For example where I live, there is a +9:30 timezone for half of the year, and a +10:30 timezone during daylight savings. This removes all the ambiquity, and allows the illlusion that UTC is a continuous stream.

We (Bloomberg) have a very nice C++ library designed on top of the IANA timezone data that will hopefully make its way to GitHub eventually. The API for that library allows the caller to specify either explicitly DST or STANDARD or an UNSPECIFIED enum value which means the API will let you know whether the resulting conversion is ambiguous so that you can take correct action. This only comes up to bite you when you are storing datetimes in non-UTC timezones. If you simply store UTC there is no ambiguity when converting to a specific location's timezone.

Maybe if you want to schedule a meeting for 4pm local time, no matter the time zone. Some countries have very unpredictable daylight saving schedules.

(For example, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551195 - "To keep on with the great work our government has done the past two years of deciding stuff with 2 or 3 days of anticipation, the government has just decided that we won't switch to DST this Sunday.")

Vehicle reservation system. If you book a car at 10am, it can't suddenly become 11am because dst changes. There are a bunch of use cases (e.g. financial processing) which require that you map that to utc.

Most things that happen in the 'real world' happen at the same local time regardless of government meddling with timezones. Microsoft had a really hard time fixing everyone's meeting times the other year, when the US decided to move the DST switchover date by a few weeks; if Exchange had stored symbolic timezones rather than numeric then nothing need have changed.

If something's scheduled for the future, either it should be scheduled absolutely (with direct reference to UTC) or with reference to its location (with a symbolic timezone). Numerical timezones are dangerous, because they look like they provide enough information but they don't.

Incidentally, please use Olson-style location-based TZ symbols, rather than three-letter zone names. The three-letter names aren't nearly as helpful when resolving DST changes.

Recurring events. Specific points in time are just that and can be represented properly, but what about that 10am meeting that happens every 2 weeks that you added into your calendar? The calendar app doesn't go create an infinite number of events into the future when you add the recurring event -- it simply stores 10:00 America/New_York and does the proper timezone conversion when for each discrete date.

No.

What we really need is timezones that are always straight hour offsets of UTC, and no DST. With that simplified, we'd keep the benefits of timezones but have less problems dealing with them.

My previous blog post [0] covered the simple case of 'Local' dates. If you're able to simplify your application code to avoid the use of timezones then that's a good thing to do, but boycott et al. isn't going to work. It might be possible if you're, say, writing a service internal to your company and all your servers are on UTC - its just a case of choosing something applicable to your domain.

[0] http://insightfullogic.com/blog/2012/dec/14/date-and-time-ja...

Then you're cringing for the wrong reasons - nearly every deployed language gets this wrong also (numeric timezones instead of descriptive ones) - java is actually one of the first to fix this stuff up.

I'm on the opposite.

In fact, I run away every time I hear "Date or Money" and [any other platform except Java or .NET] in the same sentence.

The current situation isn't too great in terms of the standard libraries - but Jodatime is still a good alternative, and at least the situation is improving.