-
Time4J
Advanced date, time and interval library for Java with sun/moon-astronomy and calendars like Chinese, Coptic, Ethiopian, French Republican, Hebrew, Hijri, Historic Christian, Indian National, Japanese, Julian, Korean, Minguo, Persian, Thai, Vietnamese
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
ISO 8601 contains durations and time intervals which are totally undervalued! (https://en.wikipedia.org/wiki/ISO_8601#Time_intervals)
E.g.: 2021-05-01T12:00:00Z/P2H
They are so convenient. Every tried to store a tuple of datetimes to model a time interval? E.g. a meeting that takes place on 2021-05-01T12:00:00Z and takes two hours. Don't store it as two datetimes! Store it as an interval: "2021-05-01T12:00:00Z/P2H"
Or are you creating an API where a duration or a time interval is expected? E.g. "give me all sales in this time period..."
Please use time intervals for that. For JVM developers, there is a library out there that has amazing support: https://github.com/MenoData/Time4J
For python developers, there is pendulum which supports most of the functionality.
ISO-8601 was a good early attempt, but unfortunately it has some negative points:
- Only offset-based time zones are allowed (which are next to useless).
- Omitting the time zone defaults to local time, which renders the time ambiguous. Defaulting to UTC makes much more sense.
- BC dates are all offset by 1 ("-1" = 2 BC). I know the reasons for this, but this could have been moved to the implementation and not exposed to the user.
- Lots of silly things like fractional-minutes and multiple ways to represent the same data bloat the spec and implementations.
This is why I rejected iso-8601 and developed my own for https://github.com/kstenerud/concise-encoding/blob/master/ct...
Examples:
2019-8-5 : August 5, 2019
-300-12-21 : December 21, 300 BC (proleptic Gregorian)
12:05:50.102 : 12:05:50 and 102 milliseconds UTC
4:00:00/Asia/Tokyo : 4:00:00 Tokyo time
2019-01-23/14:08:51.941245 : January 23, 2019, at 14:08:51 and 941245 microseconds, UTC
1985-10-26/01:20:01.105/America/Los_Angeles : October 26, 1985, at 1:20:01 and 105 milliseconds, Los Angeles time
5192-11-01/03:00:00/48.86/2.36 : November 1st, 5192, at 3:00:00, at whatever is in the place of Paris at that time (coordinate based)
en-dk has ISO 8601 though you're right it uses the comma.
https://github.com/lattera/glibc/blob/master/localedata/loca...