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.
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 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.
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.
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.
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.
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.")
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.
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.
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?! :)
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.
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.
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.
