←back to thread

189 points GordonS | 1 comments | | HN request time: 0s | source
Show context
zeroimpl ◴[] No.19533112[source]
I sometimes wish there was an actual "TIMESTAMP WITH TIME ZONE" type that stored the input timestamp as well. Basically, a version that didn't canonicalize the input by converting to UTC. This way, I can easily show timestamps to the user in the time zone they used to input them.
replies(6): >>19533287 #>>19534038 #>>19534057 #>>19534316 #>>19535066 #>>19541872 #
niftich ◴[] No.19533287[source]
I frequently wish that datetime libraries and APIs frozen in time and awkward design were given a second pass and redone in the style of Java 8 [1], which is a triumph of clarity after many years of lessons learned. Even putting out a new RFC would help move things along, because I've long felt that RFC 3339 is underspecified [2].

If datetime libraries were more thoroughly patterned after that of Java 8, there would be less need for the 'misconceptions programmers believe about datetimes' posts, and less need for the 'just use UTC' or 'maybe always-UTC isn't the right advice' posts, because the data-types are thoroughly reflective of their intended use, and their misuse is harder than in other APIs.

[1] https://docs.oracle.com/javase/8/docs/api/java/time/package-... [2] https://news.ycombinator.com/item?id=12364805

replies(3): >>19534597 #>>19535194 #>>19535410 #
1. bradleyjg ◴[] No.19535194[source]
In case anyone isn't aware, Stephen Colebourne was the specification lead for JSR-310 which eventually became java.time.* He had previously written Joda-Time an open source library which prior to the release of Java 8 was the de facto date/time library for Java for about a decade.

He'd be someone I want on any new RFC effort.