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".
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.
"floating" is a weird term, and I hate making words up, but at least it doesn't get confused in conversation with a time-zone-decorated timestamp that just happens to be in the user's local timezone.
But as long as it's possible to do what we need, which is sounds like it is, then that's what matters.
Thanks for the writeup.
EDIT: Regarding "Birthdays, Holidays and relative points in time",
MonthDay is not sufficient to describe all of the types of "floating" times, the canonical example given in RFC 2445 is of a user who wishes to appear unavailable at lunch every day, regardless of what time zone they are in. That's a more granular resolution than a day, but it's the same concept: an arbitrary precision, time-zone-less date that has no equivalent UTC start time until it is "observed".
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:
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".