Support for times greater than 24:00
Opened this issue · 5 comments
Some domains have time-of-day notations greater than 24:00, indicating that although the given time value may occur on the next calendar day, it is still associated with the previous day.
Per Wikipedia:
Time-of-day notations beyond 24:00 (such as 24:01 or 25:00 instead of 00:01 or 01:00) are not commonly used and not covered by the relevant standards. However, they have been used occasionally in some special contexts in [various countries] where business hours extend beyond midnight, such as broadcast television production and scheduling.
For instance, 25:30 on 7/1/2020 would represent the same point on the timeline as 1:30 on 7/2/2020. However, within the application context the time is still associated with the previous day (e.g. it would be displayed or billed or whatever with the previous day's data).
From what I can tell, both java.time and Threeten-Extra assume a 24-hour clock, and do not store or parse values at or greater than 24:00.
Support for this view of time seems a natural fit for ThreeTen Extra.
It would be useful to be able to pass around instances of this type, parse to/from String representation, do temporal operations on it, convert it to standard wall-clock time, etc.
This view of time would be applicable to the various types that use time. For my use case, LocalTime, LocalDateTime, ZonedDateTime would probably be what I'd need. It looks like it would be applicable to OffsetTime and OffsetDateTime as well.
I'm not sure what the best way to fit this into the javax.time API would be, if it's a whole new set of types analogous to the existing Time type, or if there's a different way to approach this.
This would be a perfectly sensible addition to ThreTen-Extra. It could be a combination of LocalTime and a number of days, or something closer to LocalTime. Various design options.
What would you call this type? UnboundedLocalTime/UnconstrainedLocalTime? ExtendedLocalTime?
I like ExtendedLocalTime or WraparoundLocalTime
I tried some experiment with similar idea and found issue:
ChronoField#HOUR_OF_DAY has ValueRange.of(0, 23)
How should such "ExtendedLocalTime" work when queried for TemporalField HOUR_OF_DAY?
Is it safe to return 29 ? It would be nice if it could because one could just reuse DateTimeFormatter.ISO_LOCAL_DATE_TIME and print 2022-12-31T29:10:10 as the formatter uses value of HOUR_OF_DAY. But there is no chance that parsing would work as there is validation on range.
And if HOUR_OF_DAY should not return 29 what should be return? 5 ? But then one can print it as 2022-12-31T05:10:10 which is wrong as 2022-12-31T29:10:10 corresponds to LocalDateTime of 2023-01-01T05:10:10
I think we have to accept that this isn't the ChronoField.HOUR_OF_DAY field. That field explicitly says it is from 0-23 and suitable for all calendar systems, which doesn't meet the goals here. So, a new field would also be needed.