search

ThreeTen / threeten

This project was the home of code used to develop a modern date and time library for JDK8. Development has moved to OpenJDK and a separate backport project, threetenbp.
http://threeten.github.io/
191 stars 37 forks source link

Problems with the name IsoEra in temporal package #339

Closed MenoData closed 10 years ago

MenoData commented 10 years ago

The combination of Iso and Era is completely wrong regarding the text and the spirit of ISO8601-standard. Well, I know your standard answer will be something like "we don't follow slavishly ISO". Okay, nobody will force you to strictly follow ISO, but then it is surely better not to use the name of ISO-standard for the era concept i.e. to have more respect for names of external standards.

Reasons: ISO does not even mention any era concept. Even worse: It speaks about years including zero year, not year-of-era (excluding zero year!). The era concept indicates another way of year counting in contradiction to ISO. A library should separate both aspects more clearly - also in class names. Therefore I suggest a name like "GregorianEra".

jodastephen commented 10 years ago

Older designs did not provide a calendar system abstraction over the ISO calendar in the same way that they did for other calendar systems. As such, this issue didn't arise. However, Oracle required a full calendar system neutral API that was inclusive of classes like LocalDate. The result of this was an abstraction that has to handle all calendar systems in the same way. And that abstraction needs eras.

Given that we have to have the concept of era and year-of-era, there were then two choices - a single ISO era for all time, or two ISO eras that relate to Gregorian/Julian concepts. While the latter may not be in the ISO-8601 spec, the spec is clearly derived from proleptic Gregorian. Moreover, I took the opinion that it was better for users to have the ability to use eras with the ISO calandar system than to get exceptions from their absence.

Calling it GregorianEra would be confusing as the chronology is called IsoChronology. We could call everything IsoProlepticGregorianChronology but thats rather a mouthful.

Finally, the YEAR field is proleptic and includes year zero. It is only YEAR_OF_ERA that does not, as it works with ERA.

MenoData commented 10 years ago

Well, I see your arguments but the fact remains that an IsoEra is a completely artificial construction just to fulfill your api requirement that every calendar should have an era concept (in my opinion rather an api problem).

I cannot imagine any useful real use case for IsoEra based on proleptic gregorian calendar because then the separation point of IsoEra CE/BCE would not even be identical to the eras AD/BC of historic calendar (with a cutoff between gregorian/julian calendar). This difference is probably even more difficult to explain to users than the non-existence of IsoEra-concept in the real world. Or: IsoEra CE/BCE should rather be like AD/BC on temporal level (same separation point), but represent just a naming alternative (what is probably most expected by users).

If you really decide to keep the name IsoEra then you should at least document that is something different to the historic era AD/BC and why.

jodastephen commented 10 years ago

We discussed this today. While ProlepticGregorianEra would be an accurate name, IsoEra is shorter. You are entirely correct that ISO does not have eras, so this concept is weird. However, it can be better to have a weird concept that throw an exception - there are design trade offs here.

As such, we agreed to leave this as is.