Comment by kuschku | Hacker News Reader

Comment by kuschku | Hacker News Reader

The only working datetime solution is JSR310.

It has separate types for

• LocalTime (milliseconds after midnight)

• LocalDate (julian day),

• LocalDateTime (julian day and milliseconds after midnight),

• Instant (nanoseconds since EPOCH),

• ZonedDateTime (which is a point in time with a timezone, and exposes both the localdatetime and the instant APIs)

All of these types have a reason to exist, and definitely shouldn't be mixed together (like python does).

• If I program an alarm clock, I'll want to use LocalTime. Even if DST starts/ends, you still wanna get woken up at 8am.

• My birthday is a LocalDate. It usually has no time information, and usually isn't depending on a timezone. An anniversary is the same.

• The moment when a loggable event happened is an Instant. The event doesn't care about timezones, only the exact time it happened.

• A calendar event is a ZonedDateTime: the meeting will happen at 10am CET, regardless of which timezone I'm in at that point.

All these types describe different concepts, and they shouldn't be mixed together. Every language should adopt JSR310. Yes, it's relatively complicated, but it's extremely precise and accurate.

And you can convert them all!

•LocalDate + LocalTime becomes LocalDateTime

• LocalDateTime.atZone(ZoneId or ZoneOffset) becomes ZonedDateTime

• Instant.atZone(ZoneId or ZoneOffset) becomes ZonedDateTime

• ZonedDateTime.toInstant() or ZonedDateTime.toLocalDateTime() exposes local datetime and instant.

• LocalDate can easilybe converted to JapaneseDate, HebrewDate, ArabicDate.

JSR 310's Instant class and notion of absolute time has always left me wondering whether any time library in any language attempts to handle relativity. Does anybody know of any?

If I'm not mistaken "chrono"[1] behaves almost the same. It calls Local[Date|Time|DateTime] Naive[Date|Time|DateTime]. ZonedDateTime is just called DateTime. It doesn't have a separate type for Instants but can convert (zoned) DateTimes to and from UNIX timestamps.

[1] https://docs.rs/chrono/0.4.19/chrono/index.html

Edit: it seems like chrono's design took lessons learned from other time libraries, including JSR-310, into account, so that explains why they are so similar.

Yeah, Chrono is also really nice, indeed. Didn’t know it was inspired by JSR310, but it makes sense now that I think about it :)

The new ES Temporal API is also inspired by the same API.

I think this crate should be used now https://time-rs.github.io/time/index.html

I haven't heard of it before! Do you know what sets it apart from chrono? It doesn't mention anything in the readme as far as I can tell.

The biggest difference between time-rs and Chrono to me is the inlined time zone type parameter. Chrono's `DateTime<FixedOffset>` is called `OffsetDateTime` in time-rs. The intention was to be able to specialize `DateTime` to the permanent UTC time zone and avoid any offset calculation, but this idea has never caught on. Also time-rs has a luxury of procedural macros which didn't exist when Chrono was first designed.

Joda's Instant corresponds to `std::time::SystemTime` in Rust. It was never intentional (source: I designed Chrono and it existed before `std::time`), but currently Chrono fills the calendar date and time while the standard library fills the monotonic and wall-clock timestamps.

To be honest, I think JSR-310 is not correct in every regard and its implementation of every ISO 8601 format is a mistake. I even started out Chrono without referring to JSR-310 (because I have designed other date and time libraries in the past). But it is much better than, say, Python datetime to which is being compared.

I'm interested in learning more about the ISO 8601 format issue. Can I read more about that anywhere?

JSR-310 contains lesser-useful fragments of ISO 8601: MonthDay, Period, Year, YearMonth, Month. They might be useful if they are agnostic to calendar systems, but they are actually just for ISO 8601.

Period is doubly problematic. It is important to realize that ISO 8601 is the standard for interchange formats, not the standard for computer data types (compare to, say, IEEE 754). As a result you need additional information to make it a proper data type standard. For ISO 8601 period you would need the actual algorithm to add it to a time point. What happens if you add 1 month (P1M) to January 30, 2021 (2021-01-30)? Would it be 2021-02-28 or 2021-03-02? Should we give both options to end users? You need a set of pluggable policies to make it work. JSR-310 Period class is pretty lacking in this regard. (In fact, pretty much every implementation of "relative delta" has the same problem. It can't be readily used in the business logic.)

IMO SystemTime should be avoided in its current state. The API is extremely limited and annoying to use for no good reason. And what's worse is that both precision and range depend on the platform.

> LocalDate (julian day)

Here, does julian day mean day number since 4713 BC or day number since the beginning of current year?

https://en.wikipedia.org/wiki/Julian_day

LocalDate is defined as the mean day since 4713 BC, yes.

This allows you to specify year, month, and day easily, and expose it as hebrew date, japanese date, julian date or gregorian date easily.

For a day relative to the current year, there’s a separate type.

How to nicely represent all these in the database layer where most things end up living at the end of the day. I have't really found a good recommendation on that to be honest specially the whole LocalDate/Time thing. Anyone has recommendations/documents to help guide that?

I find that storing ZonedDateTime in your database as a UTC epochTime (long or int datatype depending on precision required) handles the use case where you need to store a precise moment in time, and is guaranteed to work across DB implementations.

Alternatively you can use TIMESTAMP and TIMESTAMPTZ types in postgres for instant and ZonedDateTime, and serialize local date, local time, and localdatetime either to iso 8601 pr their underlying fields (millis after midnight and julian date)

What other runtime libraries besides Java implement JSR310?

The JS Temporal type is basically a clone of it, there’s a C# implementation, and rust’s chrono is very similar (but without the problematic parts).

Reply on news.ycombinator.com