I noticed that of the date-related types -- LocalDate, LocalDateTime, OffsetDateTime, ZonedDateTime -- only LocalDate accepts era as a construction parameter:
public LocalDate(int year, int month, int day);
public LocalDate(Era era, int yearOfEra, int month, int day, [NotNullAttribute] CalendarSystem calendar);
Are the era-based constructors only provided as a matter of convenience? And if so, why is it not extended to other types which limit constructors to non-era values? For instance:
public LocalDateTime(int year, int month, int day, int hour, int minute);
All of the types have an immutable Era parameter. As far as I can tell, the only way to affect Era in the other types is by the calendar used during construction.
Would someone be able to explain this design choice?
A mixture of oversight and avoiding massive overloading, basically. It would certainly make logical sense to have such a constructor in LocalDateTime
.
ZonedDateTime
and OffsetDateTime
don't have constructors accepting individual components to start with - you're expected to create them from one of the other types. So it's only really LocalDateTime
that needs anything added.
However, there's then the question of which overloads to add. There are already 8 constructors in LocalDateTime
- four variants of precision (down to minute, second, millisecond, and tick within millisecond) and two overloads for each of those to accept a CalendarSystem
or assume ISO. I don't want to double this number of constructors to 16 (and it's already odd that in 2.0 you can't directly construct a value to nanosecond precision with a constructor...)
Use of eras is pretty unusual, so rather than everyone having to pay the complexity cost of having lots of constructors to deal with, it's simpler to just construct a LocalDate
and a LocalTime
separately:
var ldt = new LocalDate(Era.Xyz, yearOfEra, month, day, calendar) +
new LocalTime(....);
That's simple and still efficient, without the headache of overload blowup.
See more on this question at Stackoverflow