7 ms·

Date and Time in Java 8: Timezones

38 points by rlmw 14y ago

codeka 14y 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.
- rlmw 14y 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);
- bromley 14y 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.html http://blog.joda.org/2009/11/why-jsr-310-isn-joda-time_4941....
bnr 14y ago
What's the use case for storing a time with timezone instead of just storing the UTC value?
- 0x0 14y 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 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 14y ago
    For the curious, the government in question was argentina.
    - thisone 14y ago
      Australia also has some interesting history with daylight savings. I remember it being used for a discussion of DateTimeOffset in .net because it could showcase all the different scenarios.
- Joeri 14y 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 14y 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.
- apaprocki 14y 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.
bjhoops1 14y ago
I cringe every time I hear "Date" and "Java" in the same sentence.
- rlmw 14y 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.
  - bjhoops1 14y ago
    Oh nice - I'll have to check that out. Standard libraries... smh
- RyanZAG 14y 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 14y ago
    Perl has had the DateTime suite of modules since early 2003. (Shameless plug since I'm the author). https://metacpan.org/release/DateTime https://metacpan.org/release/DateTime
    - joesb 14y ago
      So does Java. But, same as in Perl, it was not included in standard library.
- edwinnathaniel 14y 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.
RyanZAG 14y 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?! :)
- rlmw 14y 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-java-8-1/ http://insightfullogic.com/blog/2012/dec/14/date-and-time-ja...
- TazeTSchnitzel 14y 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.
  - RyanZAG 14y 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.
aleyan 14y 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.
- apaprocki 14y 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.
- pkulak 14y 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 14y 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.

38 points by rlmw 14y 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.

rlmw 14y 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);
bromley 14y 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.html http://blog.joda.org/2009/11/why-jsr-310-isn-joda-time_4941....

bnr 14y ago

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

0x0 14y 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 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 14y ago
  For the curious, the government in question was argentina.
  - thisone 14y ago
    Australia also has some interesting history with daylight savings. I remember it being used for a discussion of DateTimeOffset in .net because it could showcase all the different scenarios.
Joeri 14y 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 14y 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.
apaprocki 14y 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.

bjhoops1 14y ago

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

rlmw 14y 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.
- bjhoops1 14y ago
  Oh nice - I'll have to check that out. Standard libraries... smh
RyanZAG 14y 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 14y ago
  Perl has had the DateTime suite of modules since early 2003. (Shameless plug since I'm the author). https://metacpan.org/release/DateTime https://metacpan.org/release/DateTime
  - joesb 14y ago
    So does Java. But, same as in Perl, it was not included in standard library.
edwinnathaniel 14y 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.

RyanZAG 14y 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?! :)

rlmw 14y 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-java-8-1/ http://insightfullogic.com/blog/2012/dec/14/date-and-time-ja...
TazeTSchnitzel 14y 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.
- RyanZAG 14y 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.

aleyan 14y 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.

apaprocki 14y 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.
pkulak 14y 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 14y 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.