7 ms·

I'm very happy about this. The fact that Temporal forces you to actually deal with the inherent complexities of time management (primarily the distinction betwe

I'm very happy about this. The fact that Temporal forces you to actually deal with the inherent complexities of time management (primarily the distinction between an instant and a calendar datetime) makes it incredibly difficult to make the mistakes that Date almost seems designed to cause. It's a bit more verbose, but I'll take writing a handful of extra characters over being called at 3AM to fix a DST related bug any day of the week.

throwaway_12629 6mo ago
Technically, you're not likely to to have to fix a DST bug at 3AM any day but Sunday.
- usefulcat 6mo ago
  // call foo() one day from now: sleep(86400); foo();
  - hdjrudni 6mo ago
    Sorry, sleep returned a Promise and you didn't await it. You called foo() immediately.
  - koakuma-chan 6mo ago
    What you want there is to stop saying "day" and instead say "24 hours." This way the code is correct and you don't need to deal with time weirdness.
    - danbruc 6mo ago
      No, because if I want something to happen everyday at 12 o'clock, I have to wait for one day, if I wait for 24 hours, I will be off by an hour for half of the year.
      - loloquwowndueo 6mo ago
        Only if you live in one of the brain dead countries that observe the dst anachronism.
        eureka7 6mo ago
        ok, but they still observe it and you still have to deal with it in your code. our personal convictions don't change that fact.
      - koakuma-chan 6mo ago
        Why do you want something to happen everyday at 12 o'clock specifically? If this is truly what you want, sure.
        danbruc 6mo ago
        Lunch break reminder popup?
    - mklepaczewski 6mo ago
      You seem to assume that a day always has 24 hours. Common (but not only) non-24h day lengths are: - 23 hours - 25 hours - 24 hours 1 second - 23 hours 59 minutes 59 seconds You could assume that a day isn't exactly 24 hours, but it's close-ish to 24 hours. Nope, not even close. And that assumes that we can treat an hour as a precise measure of time (we can't). On some systems, even a second is not a precise measure of time (second smearing). To make things worse, those are "simple" edge cases. Time is hard. I'm not sure if I can make any statement about time that is true.
      - koakuma-chan 6mo ago
        I am saying that you shouldn't use day as a unit of time. You should use second, minute, hour, etc, because these have a constant duration. sleep(86400) should reliably make your thread sleep for at least 24 hours.
        mklepaczewski 6mo ago
        It depends on the context and the system you’re working with. In some systems, an hour may last 3599, 3600 or 3601 seconds (due to the leap second), a minute may be 59,60 or 61 seconds. Even a second is not always a „true” second. There’s no single time unit that works for all situations.
- dskloet 6mo ago
  That's a great example of the kind of wrong assumption that makes dealing with dates and times so challenging. Some countries start on a Friday or Saturday and until 2022 Iran could start any day of the week although never at 3AM.
- manarth 6mo ago
  Some countries alter their observance of DST in line with their observance of Ramadan, which means that the time-offset changes aligned with Ramadan. Ramadan is observed from one visual sighting of a crescent moon to the next. Cloud conditions may prevent sighting and thereby alter the official start of Ramadan for an individual location, and from time-to-time, the start of a country's change in timezone.
  - jacquesm 6mo ago
    Cue a longish article titled 'Falsehoods Programmers Believe About Time'
  - troad 6mo ago
    > Some countries alter their observance of DST in line with their observance of Ramadan, which means that the time-offset changes aligned with Ramadan. Only Morocco does this, I believe, and it's not even clear that that's actually official time at this point. In 2018, Morocco abolished DST, but it seems unclear what that means in practice. I'd love it if someone from Morocco could weigh in on what the actual situation is on the ground. Do people still change their clocks for Ramadan? Would they be annoyed if a website kept Moroccan users on standard time during Ramadan?
SOLAR_FIELDS 6mo ago
In this day and age when a natural language query can produce the most AbstractBeanFactoryFactoryBeanFactory boilerplate at the same rate as a much more concise equivalent, does verbosity matter as much?
- zelphirkalt 6mo ago
  If you want to understand what is going on at all, then yes, good abstraction layers do matter, and a lot at that. Hashtag cognitive debt.
  - SOLAR_FIELDS 6mo ago
    Sure, but if I can summon up a summary of what’s going on for those abstraction layers in a matter of seconds, I don’t particularly care whether they were overly verbose or not. There’s no world where you can hand me a pile of code and expect me to be able to comprehend it faster than an LLM can walk the stack anymore, even the most beautiful pristine code that would make Linus Torvalds praise you is easier to have an LLM parse it and explain it to you than doing it yourself. And the LLM doesn’t care. You could hand it a pile of the best code ever and a pile of brainfuck and probably the difference between comprehending one over the other is in the seconds if not milliseconds of compute time.
    - zelphirkalt 6mo ago
      This works only until it doesn't. The stochastic nature of LLMs will not go away. When you have to fix that bug, but the explanations of the LLM are incorrect (root) cause analysis, and you have to dig into the code yourself, you will regret not having taken more care earlier. I have had numerous scenarios in my latest project, in which the LLMs simply did not get on the right track, when I asked them about some issue I saw with a widget or making a custom widget (Python, tkinter). I don't think it will fare much better when analyzing existing code, because ultimately it does not understand things.
      - SOLAR_FIELDS 6mo ago
anowell 6mo ago
Agreed. We've almost eradicated our usage of JS Date - fixing plenty of bugs along the way, and then I extracted thousands of lines of conversions and formatting from our production app (scheduling focused) into a temporal-fun package to make it Temporal more ergonomic for lots of common cases. npmjs.com/package/temporal-fun
- 698969 6mo ago
  That looks neat although your package is missing a link to the source repository.
  - anowell 6mo ago
    Good catch. Will get that added today. github.com/howie-code/temporal-fun
- lightwords 6mo ago
  Word of warning Temporal relies on the Intl API for formatting, and support in Chrome is very limited due to their binary size constraints. As a result, you'll need to polyfill unsupported languages using format.js
  - rafram 6mo ago
    $ du -sh '/Applications/Google Chrome.app' 1.3G /Applications/Google Chrome.app
    - lightwords 6mo ago
      There are numerous reports on this being an issue e.g. https://issues.chromium.org/issues/40624456 https://issues.chromium.org/issues/40624456
      - anowell 6mo ago
        Thanks for the heads up. Will think on this and will probably just document the polyfill.

throwaway_12629 6mo ago

Technically, you're not likely to to have to fix a DST bug at 3AM any day but Sunday.

usefulcat 6mo ago
// call foo() one day from now: sleep(86400); foo();
- hdjrudni 6mo ago
  Sorry, sleep returned a Promise and you didn't await it. You called foo() immediately.
- koakuma-chan 6mo ago
  What you want there is to stop saying "day" and instead say "24 hours." This way the code is correct and you don't need to deal with time weirdness.
  - danbruc 6mo ago
    No, because if I want something to happen everyday at 12 o'clock, I have to wait for one day, if I wait for 24 hours, I will be off by an hour for half of the year.
    - loloquwowndueo 6mo ago
      Only if you live in one of the brain dead countries that observe the dst anachronism.
      - eureka7 6mo ago
        ok, but they still observe it and you still have to deal with it in your code. our personal convictions don't change that fact.
    - koakuma-chan 6mo ago
      Why do you want something to happen everyday at 12 o'clock specifically? If this is truly what you want, sure.
      - danbruc 6mo ago
        Lunch break reminder popup?
  - mklepaczewski 6mo ago
    You seem to assume that a day always has 24 hours. Common (but not only) non-24h day lengths are: - 23 hours - 25 hours - 24 hours 1 second - 23 hours 59 minutes 59 seconds You could assume that a day isn't exactly 24 hours, but it's close-ish to 24 hours. Nope, not even close. And that assumes that we can treat an hour as a precise measure of time (we can't). On some systems, even a second is not a precise measure of time (second smearing). To make things worse, those are "simple" edge cases. Time is hard. I'm not sure if I can make any statement about time that is true.
    - koakuma-chan 6mo ago
      I am saying that you shouldn't use day as a unit of time. You should use second, minute, hour, etc, because these have a constant duration. sleep(86400) should reliably make your thread sleep for at least 24 hours.
      - mklepaczewski 6mo ago
        It depends on the context and the system you’re working with. In some systems, an hour may last 3599, 3600 or 3601 seconds (due to the leap second), a minute may be 59,60 or 61 seconds. Even a second is not always a „true” second. There’s no single time unit that works for all situations.
dskloet 6mo ago
That's a great example of the kind of wrong assumption that makes dealing with dates and times so challenging. Some countries start on a Friday or Saturday and until 2022 Iran could start any day of the week although never at 3AM.
manarth 6mo ago
Some countries alter their observance of DST in line with their observance of Ramadan, which means that the time-offset changes aligned with Ramadan. Ramadan is observed from one visual sighting of a crescent moon to the next. Cloud conditions may prevent sighting and thereby alter the official start of Ramadan for an individual location, and from time-to-time, the start of a country's change in timezone.
- jacquesm 6mo ago
  Cue a longish article titled 'Falsehoods Programmers Believe About Time'
- troad 6mo ago
  > Some countries alter their observance of DST in line with their observance of Ramadan, which means that the time-offset changes aligned with Ramadan. Only Morocco does this, I believe, and it's not even clear that that's actually official time at this point. In 2018, Morocco abolished DST, but it seems unclear what that means in practice. I'd love it if someone from Morocco could weigh in on what the actual situation is on the ground. Do people still change their clocks for Ramadan? Would they be annoyed if a website kept Moroccan users on standard time during Ramadan?

SOLAR_FIELDS 6mo ago

In this day and age when a natural language query can produce the most AbstractBeanFactoryFactoryBeanFactory boilerplate at the same rate as a much more concise equivalent, does verbosity matter as much?

zelphirkalt 6mo ago
If you want to understand what is going on at all, then yes, good abstraction layers do matter, and a lot at that. Hashtag cognitive debt.
- SOLAR_FIELDS 6mo ago
  Sure, but if I can summon up a summary of what’s going on for those abstraction layers in a matter of seconds, I don’t particularly care whether they were overly verbose or not. There’s no world where you can hand me a pile of code and expect me to be able to comprehend it faster than an LLM can walk the stack anymore, even the most beautiful pristine code that would make Linus Torvalds praise you is easier to have an LLM parse it and explain it to you than doing it yourself. And the LLM doesn’t care. You could hand it a pile of the best code ever and a pile of brainfuck and probably the difference between comprehending one over the other is in the seconds if not milliseconds of compute time.
  - zelphirkalt 6mo ago
    This works only until it doesn't. The stochastic nature of LLMs will not go away. When you have to fix that bug, but the explanations of the LLM are incorrect (root) cause analysis, and you have to dig into the code yourself, you will regret not having taken more care earlier. I have had numerous scenarios in my latest project, in which the LLMs simply did not get on the right track, when I asked them about some issue I saw with a widget or making a custom widget (Python, tkinter). I don't think it will fare much better when analyzing existing code, because ultimately it does not understand things.
    - SOLAR_FIELDS 6mo ago

anowell 6mo ago

Agreed. We've almost eradicated our usage of JS Date - fixing plenty of bugs along the way, and then I extracted thousands of lines of conversions and formatting from our production app (scheduling focused) into a temporal-fun package to make it Temporal more ergonomic for lots of common cases. npmjs.com/package/temporal-fun

698969 6mo ago
That looks neat although your package is missing a link to the source repository.
- anowell 6mo ago
  Good catch. Will get that added today. github.com/howie-code/temporal-fun
lightwords 6mo ago
Word of warning Temporal relies on the Intl API for formatting, and support in Chrome is very limited due to their binary size constraints. As a result, you'll need to polyfill unsupported languages using format.js
- rafram 6mo ago
  $ du -sh '/Applications/Google Chrome.app' 1.3G /Applications/Google Chrome.app
  - lightwords 6mo ago
    There are numerous reports on this being an issue e.g. https://issues.chromium.org/issues/40624456 https://issues.chromium.org/issues/40624456
    - anowell 6mo ago
      Thanks for the heads up. Will think on this and will probably just document the polyfill.