Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
An often ignored part of the standards are how to represent durations (time spans).
See http://xml.coverpages.org/ISO-FDIS-8601.pdf (section: 5.5.4.2 Representation of time-interval by duration only, pg. 21)
Would like to see more json parsers in static languages allow me to define a field as a time span and can serialize into the valid format.
For an example, see this proposal in Crystal: https://github.com/crystal-lang/crystal/issues/11942
Example: A duration of 15 days, 5 hours, and 20 seconds would be:
A link was added from "Europe/Kiev" to "Europe/Kyiv" in the included-by-default backward file [0], so that any user that doesn't exclude that file will simply treat the old name as an alias for the new name.
[0] https://github.com/eggert/tz/commit/e13e9c531fc48a04fb8d064a...
This is basically why I ended up rolling my own text date format for Concise Encoding: https://github.com/kstenerud/concise-encoding/blob/master/ct...
ISO 8601 and RFC 3339 are fine for dates in the past, but they're not great as a general time format.
I maintain https://github.com/photostructure/tz-lookup which does this task.
*Every single time* I update the tz source file some arbitrary set of zone names and offsets change. Look at the churn and enjoy the schadenfreude: https://github.com/photostructure/tz-lookup/commits/main/tes...