Rerouted (cache, verified). The original is gone. This copy comes from a Lamdera package cache made before it went. The Lamdera package server serves a copy recovered from a Lamdera package cache from 2021-02-13.
What we checked: Rebuilt from the unpacked sources in a Lamdera package cache (5 copies agree), which Elm only writes after the published SHA-1 checked out; elm.json is byte-identical to package.elm-lang.org's; the exposed modules match docs.json; the zip is our own, so its SHA-1 is not the published one.
The Lamdera compiler uses this copy and prints a one-line notice saying so. elm itself fails to download this version.
Details · package.elm-lang.org's zip: https://github.com/ringvold/elm-iso8601-date-strings/zipball/1.0.2/
NOTE: This is a temporary fork to get the features in this PR: https://github.com/rtfeldman/elm-iso8601-date-strings/pull/15
Convert ISO-8601 date strings into POSIX times.
This package takes the view that it is a mistake to use ISO-8601 strings as a data transfer format. Nevertheless, third-party endpoints may use them, so even if we'd rather avoid them, sometimes they may be unavoidable.
The only design goal of this package is to "correct the mistake" by translating
ISO-8601 strings to and from Time.Posix values. If it encounters a UTC offset
in the string, it normalizes and discards it such that the resulting Time.Posix
value is in UTC no matter what.
That's all this package does, and all it aims to do!
Integer milliseconds since the epoch is a better choice for data transfer because ISO-8601 strings can potentially include a UTC offset.
This is much worse than not having the possibility of including a UTC offset. Consider:
Even without the UTC offset, an ISO-8601 string is still much larger to transfer than an integer. The usual argument in favor of ISO-8601 strings is that they are more human-readable than integers, but making data readable for humans is a better job for developer tools than data transfer formats between machines.