TL;DR: Apps like mine need to store both universally unique moments in time, and times that vary with location just like ‘human time’ does. But unless I’m missing something, Elm 0.19’s time paradigm alienates the latter use case - and deprecates the best library for the job.
Greetings, Elm Discourse! I just signed up and this is my first post, but I’ve been reading these threads all day and there is a lot of cool stuff going on. (I wish there wasn’t such an unusually short 10-day cutoff, there’s a lot of “old” topics I’d want to give input on, and many threads were prematurely killed by it before anything could be said. I hope that doesn’t happen to this one.)
I’m upgrading my project to Elm 0.19, and I’m perfectly excited to do so. I also like the simplicity of the new Time API, and I started to switch to it from the old
elm-community/elm-time because I want long-term support and it seemed well thought out:
human time should basically never be stored in your
Modelor database! It is only for display!
I was fully on board until I started switching my project over - and started to remember why I had chosen the pleasant and comprehensive
elm-time library in the first place. The documentation cited above succinctly boils down time to Human, Posix, and Zones, which is fine, but I’m starting to see that the “never store Human Time” bit, which clearly drove the design of the new library, seems to have a huge oversight: There are applications whose purpose is precisely that: to store human time.
Edit for clarity: By “human time” I don’t necessarily mean the formatted final product, but time in “human parts”: the Date, plus what’s on the local clocks.
Time.Posix values can’t be used for this, because (in a sense) they already have a time zone (!) built in, UTC (which is shift-able, but you can’t store a time without one).
Take my phone’s Alarm Clock for example: I have an Alarm set for 8:00 am. Perhaps I was in LA at the time I made that alarm. I fly to New York for a week. During that week, my alarm still works as expected, waking me up at 8:00 am.
An Elm implementation, however, naively using the new Time API the way it was designed (for global ‘moments’ in time such as server requests or phone calls) would look at that global moment and use the device’s local information (now set to NY time) to decide that I actually want to be woken up before the crack of dawn at 5:00 am - causing my device’s prompt defenestration.
Yikes. This seems to be a hole in the use cases covered by the library, because there is simply no way to say “8am everywhere” instead of an unchanging offset from the epoch. I’m looking for ideas to work around this.
[Edit for clarity: the Alarm Clock is an oversimplified example - it could be done without Dates at all, storing only the Time of Day. The actual code I need help with is below! ]
I realized the
elm-time library I was using handles this quite nicely:
DateTimes are stored internally as a
Date cleverly paired with a simple integer
Offset for the particular time within said date. In fact this works especially well since my Todo-list application (the current project) will also handle the case where a Date is assigned to a task with no particular time of day (a common desire), in which case that offset can just be omitted. Example code:
type TaskMoment = Unset | LocalDate Date | LocalMoment DateTime | UniversalMoment Time.Posix
Sadly, that library is now officially deprecated (
time-deprecated), with the new packages supposed to be a “better way to model time”, yet, no official way of storing human time from what I can tell. Would love to hear this isn’t the case!