Date and Time in Java 8: Timezones

http://www.insightfullogic.com/blog/2012/dec/19/date-and-time-java-8-2/

by rlmw • 14 years ago

38 25 14 years ago

codeka• 14 years ago

This is so long overdue, but I feel like I've been using Joda Time for so long that the benefit of having it in the platform is kind of outweighed by the hassle of learning a new API.

bromley• 14 years ago

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

rlmw3• 14 years ago

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

bnr• 14 years ago

What's the use case for storing a time with timezone instead of just storing the UTC value?

0x0• 14 years ago

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

JonnieCache• 14 years ago

For the curious, the government in question was argentina.

Joeri• 14 years ago

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.

andrewaylett• 14 years ago

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.

apaprocki2• 14 years ago

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.

bjhoops12• 14 years ago

I cringe every time I hear "Date" and "Java" in the same sentence.

RyanZAG3• 14 years ago

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.

autarch• 14 years ago

Perl has had the DateTime suite of modules since early 2003. (Shameless plug since I'm the author). https://metacpan.org/release/DateTime

edwinnathaniel• 14 years ago

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.

rlmw3• 14 years ago

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.

bjhoops12• 14 years ago

Oh nice - I'll have to check that out. Standard libraries... smh

RyanZAG3• 14 years ago

The real solution is to get timezones thrown out. All they do is waste the time of everyone involved and create complicated issues around travel, finance, computing, etc.

They have no real benefit - if you want to come into work later in winter because it's dark where you live then just come in later! Changing time to suite this madness is insane, broken, and requires immediate fixes.

If we could get all the OS markets/net service providers to agree to a boycott, then nobody would even notice DST is gone as they just get their time from their phone/computer/radio/etc anyway.

I'll get the pitchforks and we can get this started. Anybody with me?! :)

TazeTSchnitzel• 14 years ago

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.

RyanZAG3• 14 years ago

Sorry, I completely messed up my post. Replace every 'timezone' in the post with 'day light savings' - it will also make a lot more sense then.

rlmw3• 14 years ago

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

aleyan• 14 years ago

I wonder how this library deals with ambiguous times around daylight savings. For example on the day of switching from summertime to wintertime the clock goes from 2:59 am to 2:00 am again resulting in the hour being repeated. If you know the correct time zone for that timestamp, it is still ambiguous which of the two UTC times it maps to.

pkulak• 14 years ago

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.

keeperofdakeys• 14 years ago

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.

apaprocki2• 14 years ago

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.

Date and Time in Java 8: Timezones

Related Stories