As part of the Elm 0.19 release, Evan implemented the elm/time package. In his notes for the package, he identifies remaining issues that need attention and is soliciting feedback. Specifically, time-zones seem to be the biggest concern.
Converted all parsing from elm-community/parser-combinator to elm-tools/parser. This was specifically to prepare for the conversion to elm-19. I put substantial effort into improving the error messages; there is an example application that shows this.
The time zone functionality is complete, including the Elm representation of the IANA database with much compression optimization and parsed lazily. It is an impressive achievement, and yet there are still challenges:
1. Even the compressed database may be larger than many users will desire.
1. Whenever the changes in the IANA database are updated into the Elm representation, the Elm names are changed and this triggers a major version change when deployed as an updated package.
I see two “obvious” choices that identify the extreme endpoints for solutions to the time zone challenged:
Make the IANA functionality an API to the IANA service.
Pros
Lower the Elm app’s memory footprint for IANA functionality.
Caching can improve the time to retrieve.
Eliminate the IANA Elm name changes that trigger the major version change
Cons
Reliability of the API connection.
Can no longer be released as a package.
Keep and improve the existing Elm version of the IANA database.
Pros
Keeps the integrity of the existing package functionality.
Much faster.
Much more reliable.
Cons
Larger memory footprint.
Is there a way to fix the major revision change problem?
I can see keeping both alternatives and letting users choose which fits their needs better.
Or perhaps there are attractive alternative solutions in-between the above two.
Does ‘dead code elimination’ not solve this? I remember way back probably on the old elm-dev mailing list something about how the large IANA database would not cause a problem because DCE, but perhaps I do not remember correctly.
I can tell you what decisions were made in Elixir-land, which went through major improvements w.r.t. date, time, datetime and timezone handling in the last couple of versions, a process which I was actively involved in myself (standing on the shoulders of giants, though!):
The choice there was explicitly made to have timezone-support outside of the Elixir core, to keep the release cycles of tzdata and core independent.
The Elixir core supports definitions for common date/time/datetime types, both ones without timezone information and those with timezone information, mostly for coordination between libraries (so they have a common datatype they share).
The core defines an API that a timezone-provider might implement. Many applications use a package that once a day polls tzdata for the latest updates, but on some embedded devices, the one available at cross-compilation time is used instead, or a hard-coded one is used.
Drawing inspiration from well-known date/time-handling libraries such as Joda-time, in Elixir the decision was made to make the definitions future-proof by allowing people to provide custom calendar behaviours, beside the ISO8601, Gregorian proleptic, one (which is implemented as part of Elixir core).
Stringifying dates and times is done using the ISO8601-standard (For non-UTC datetimes with a timezone, the zone designator is followed by the name of the timezone, space-separated, which is non-standardized but extremely common across platforms). Custom locales might take the datastructure and create a string from it in whatever way they see fit, but this was decided to be outside of the scope of the core date/time-implementation.
It was decided not to bother with leap second handling in Elixir, mostly because the Elixir clock is at the whim of the computer clock’s handling of leap seconds, which varies from platform to platform (without any way to tell from user-land). Of course, implementing a custom calendar behaviour that does this is possible, albeit extremely difficult. (Also because the mapping UTC <-> POSIX is complex because POSIX time does not have a notion of leap seconds at all.)
For Elm, I definitely think that having both approaches side-by-side is a good idea. For apps that need it, having the option to check in real-time for the newest tzdata-version is wonderful. For apps that don’t, you can keep the dependencies a lot lower by only using the latest hard-coded tzdata that you supply with it.
Can you explain why ‘the names are changed’ whenever the Elm-representation is updated? Are timezone-names exposed as symbols, rather than elements in a data structure?
@rupert I thought about this also; I don’t think you can do ‘dead code elimination’ because you don’t know when the user’s Elm program is going to request a particular timezone. So you don’t know which code is ‘dead’. Which is why the lazy parsing.
Can you explain why ‘the names are changed’ whenever the Elm-representation is updated? Are timezone-names exposed as symbols, rather than elements in a data structure?
They ARE defined as Elm symbols. What is puzzling to me is, if the timezones are only added, that should result in a “minor” change as opposed to a “major” change. To my understanding, timezones should never be removed; they will always need to be remembered as history for the “old times”.
Oh, and thanks for your detailed feedback; much good grist to chew on.
I think the problem here is that the new version of the package is generated programmatically from the new tzdata database.
This database only ever contains the new timezones, it does not contain historical information. So therefore, there is no real way to know if something was only an addition or not.
I think this should be explored outside of elm-community.
There are lots of design questions here, and I think we’d benefit from having interested people explore the topic. If one becomes popular, and then the author disappears, maybe it should come back into elm-community.
For folks looking for a project, there are like six different ones here.
For @oldfartdeveloper, this may mean moving the work you have done to be under your name. From there you can pick the path that seems most promising to you. And ultimately, different approaches may work better or worse for different people. I don’t think there we know the true answer right now.
