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".
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.
Hope that helps!
[0] http://en.wikipedia.org/wiki/ISO_8601