3 ms·

I tried to use Temporal just this past week, and I have to be honest… the spec and documentation are painful. I spent three full days with it and still don’t un

I tried to use Temporal just this past week, and I have to be honest… the spec and documentation are painful. I spent three full days with it and still don’t understand why it’s designed the way it is. Other recent additions to stdlib have followed a fairly consistent pattern: design low level but with existing use cases and solutions in mind, explain the design in terms of migration path for library authors or in terms of usage comparisons to those libraries. Temporal just has… a bunch of data types with very little in the way of explanation of what they are. And some of them are quite similar but have slightly different semantics and APIs to achieve the same thing. It’s not entirely clear why most of the data types exist in the first place. Like, I don’t want a TimeZone class, and I don’t want multiple kinds of Instants. I want a Date, a Duration, and clear semantics about how they interact with each other and with time zones. Anyway I ended up putting the work I was doing on hold because it became such a time sink, but when I come back to it I fully expect to look at my WIP stashes, and run screaming toward date-fns or whatever. I mean no disrespect to the standards authors/contributors (in case any are reading), I’m sure standardizing anything to do with dates/times is even more challenging than anything else you deal with. I just… wonder if the low level design approach may have forced an unnecessary design in this case, and wish there was a somewhat more pragmatic approach for something end users and library authors alike routinely get wrong in subtle but important ways.

Macha 5y ago
> I want a Date, a Duration, and clear semantics about how they interact with each other and with time zones. I think at this stage the only libraries I've seen to manage this clearly are the ones that cleanly seperate the concept of "LocalDate[Time]" from "ZonedDateTime" (which is different to OffsetDateTime, which is only useful when backwards looking because offsets are subject to change in future, and so you should probably just use a Zoned variant). While people might appreciate the simplicity of a single DateTime class, it just leads to unclear handling in application code of where the conversions happening and confusion as to what's actually going on with time zones.
- eyelidlessness 5y ago
  This could be addressed at least for the most common cases by making the API more explicit: if you want a non-zoned DateTime, you have to say so and accept its caveats. Otherwise you’re getting a (local by default) zoned DateTime and its TZ can be manipulated to accomplish other date/time math in a predictable way. The mix of zoned/not is a valid use case but almost certainly a specialized one that shouldn’t be the core API.
  - dvt 5y ago
    > The mix of zoned/not is a valid use case but almost certainly a specialized one that shouldn’t be the core API. I'm curious, where is this ever a valid use case? The idea of an unzoned DateTime doesn't make sense to me. I guess if you're building software that lives in orbit or on other planets?
    - eyelidlessness 5y ago
      My personal use case that I explain in the “just use UTC isn’t good enough” case: I take meds 2-3 times a day that are short acting and time sensitive. I need them at ~9am and ~1pm to function. Local time, wherever I am. For the unzoned case I need my reminders to notify me at the same local time wherever I travel. For the mixed case I need to be able to apply local changes where the unzoned solution isn’t available. These are ADHD meds, I have severe executive dysfunction and I depend on reminders for this. Traveling from Seattle to DC, this is literally the difference of whether I can function at all before lunchtime. Traveling further I might as well not go at all.
    - q-rews 5y ago
      I want to wake up at 8:00 regardless of my timezone. I don’t want to wake up at “8:00 NYC” when I’m in Europe nor should I need to adjust the alarm every time I change timezone.
      - skissane 5y ago
        That’s a good case for an unzoned time data type - storing a time without an associated date or timezone. There are some scheduling use cases where such a type is useful - such as your alarm clock example, or suppose a chain of retail stores has standard opening hours of 9am-5pm regardless of the time zone the store is in. But a combined datetime (both date and time) in an unspecified non-UTC timezone is far less useful. As I mentioned in another comment, there are some rare use cases where it is genuinely appropriate, but far more often if you give people such a type they’ll use it to store data in a single specific time zone, without being explicit about what that time zone is-which is a bad practice.
justshowpost 5y ago
Spending more time on time... Sad but somewhat hilarious.
brundolf 5y ago
Somebody could probably build a tiny, more ergonomic library on top of the Temporal foundation. The original Date implementation made the mistake of trying to be too high-level as a language primitive, and we can see where that got us. I can definitely understand the authors not wanting to make the same mistake again; I think it's well and good for the platform primitives to favor being comprehensive and unopinionated over being ergonomic or easy to use.
- eyelidlessness 5y ago
  > Somebody could probably build a tiny, more ergonomic library on top of the Temporal foundation That’s my point. Most recent standards try to optimize for this. I would be surprised if you could based on my experience with the APIs. Maybe I’m not well enough versed to see how it would be written. But its design feels much more likely to be something where the native types are passed around or substituted. They’re not designed to interoperate with each other as far as I can tell.
petre 5y ago
It's awful, just like Date. We have to keep using moment.js due to Highcharts, timezones and locales. It's quite easy to use if you're careful about mutating objects and the API is not brain damaged. We still use jQuery as well, it's a breath of fresh air compared to native Js APIs, except maybe fetch. Go ahead and downvote, I couldn't care less. We can't keep changing our platform every time a new and hip way of doing things pops up.

Macha 5y ago

> I want a Date, a Duration, and clear semantics about how they interact with each other and with time zones. I think at this stage the only libraries I've seen to manage this clearly are the ones that cleanly seperate the concept of "LocalDate[Time]" from "ZonedDateTime" (which is different to OffsetDateTime, which is only useful when backwards looking because offsets are subject to change in future, and so you should probably just use a Zoned variant). While people might appreciate the simplicity of a single DateTime class, it just leads to unclear handling in application code of where the conversions happening and confusion as to what's actually going on with time zones.

eyelidlessness 5y ago
This could be addressed at least for the most common cases by making the API more explicit: if you want a non-zoned DateTime, you have to say so and accept its caveats. Otherwise you’re getting a (local by default) zoned DateTime and its TZ can be manipulated to accomplish other date/time math in a predictable way. The mix of zoned/not is a valid use case but almost certainly a specialized one that shouldn’t be the core API.
- dvt 5y ago
  > The mix of zoned/not is a valid use case but almost certainly a specialized one that shouldn’t be the core API. I'm curious, where is this ever a valid use case? The idea of an unzoned DateTime doesn't make sense to me. I guess if you're building software that lives in orbit or on other planets?
  - eyelidlessness 5y ago
    My personal use case that I explain in the “just use UTC isn’t good enough” case: I take meds 2-3 times a day that are short acting and time sensitive. I need them at ~9am and ~1pm to function. Local time, wherever I am. For the unzoned case I need my reminders to notify me at the same local time wherever I travel. For the mixed case I need to be able to apply local changes where the unzoned solution isn’t available. These are ADHD meds, I have severe executive dysfunction and I depend on reminders for this. Traveling from Seattle to DC, this is literally the difference of whether I can function at all before lunchtime. Traveling further I might as well not go at all.
  - q-rews 5y ago
    I want to wake up at 8:00 regardless of my timezone. I don’t want to wake up at “8:00 NYC” when I’m in Europe nor should I need to adjust the alarm every time I change timezone.
    - skissane 5y ago
      That’s a good case for an unzoned time data type - storing a time without an associated date or timezone. There are some scheduling use cases where such a type is useful - such as your alarm clock example, or suppose a chain of retail stores has standard opening hours of 9am-5pm regardless of the time zone the store is in. But a combined datetime (both date and time) in an unspecified non-UTC timezone is far less useful. As I mentioned in another comment, there are some rare use cases where it is genuinely appropriate, but far more often if you give people such a type they’ll use it to store data in a single specific time zone, without being explicit about what that time zone is-which is a bad practice.

justshowpost 5y ago

Spending more time on time... Sad but somewhat hilarious.

brundolf 5y ago

Somebody could probably build a tiny, more ergonomic library on top of the Temporal foundation. The original Date implementation made the mistake of trying to be too high-level as a language primitive, and we can see where that got us. I can definitely understand the authors not wanting to make the same mistake again; I think it's well and good for the platform primitives to favor being comprehensive and unopinionated over being ergonomic or easy to use.

eyelidlessness 5y ago
> Somebody could probably build a tiny, more ergonomic library on top of the Temporal foundation That’s my point. Most recent standards try to optimize for this. I would be surprised if you could based on my experience with the APIs. Maybe I’m not well enough versed to see how it would be written. But its design feels much more likely to be something where the native types are passed around or substituted. They’re not designed to interoperate with each other as far as I can tell.

petre 5y ago

It's awful, just like Date. We have to keep using moment.js due to Highcharts, timezones and locales. It's quite easy to use if you're careful about mutating objects and the API is not brain damaged. We still use jQuery as well, it's a breath of fresh air compared to native Js APIs, except maybe fetch. Go ahead and downvote, I couldn't care less. We can't keep changing our platform every time a new and hip way of doing things pops up.