Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Parsing dates in non-ISO misses requested chronology #268

Closed
jodastephen opened this Issue Feb 19, 2013 · 2 comments

Comments

Projects
None yet
1 participant
Owner

jodastephen commented Feb 19, 2013

Code was added to allow dates to be parsed in non-ISO chronologies. However, this doesn't fully take into account the chronology of the formatter as intended in the design.

There are two chronologies in use

  • effective/parsing - used during the parsing and resolving process, either a parsed chronology, or the formatter chronology, or ISO.
  • requested - used after resolving to convert any date output to the requested chronology, thus the returned TemporalAccessor would be of the requested chronology, not the effective/parsed chronology.

Parse string "Minguo 1234-06-30" using a "formatter.withChronology(ThaiBuddhistChronology)" will parse the date using Minguo, and then convert the date to Thai before returning it.

Owner

jodastephen commented Mar 30, 2013

On further examination, making this change would be really hard/complex and only benefit very limited use cases. Since most users will specify a concrete type as part of the parse (using ::from method reference) the chronology is already being applied. The withChronology and withZone methods on DateTimeFormatter are therefore best left as defaults.

Javadoc clarification: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/569031ace043

The use during formatting turned out to be incomplete and capable of improvement. In particular, some edge cases that would confuse users, such as expecting a YearMonth to be converted to another calendar system, will now throw exceptions: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/999f123d8687

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment