4 ms·

No - the master's answer is that you use one or the other depending on whether you are representing absolute time or clock/calendar time. The expertise lies in

No - the master's answer is that you use one or the other depending on whether you are representing absolute time or clock/calendar time. The expertise lies in understanding the difference between those two things, which one your use case falls into, and how to ensure other developers and the very APIs provided by your platform do not make silent assumptions about that decision. Often it feels like you can "just use UTC" because it's hard to imagine the fail states, and APIs often make tz assumptions for you so you may never notice those fail states (occasionally your software will just be buggy and annoy a user, decreasing the feeling of quality and trust - it may never result in a disaster).

naasking 2y ago
There is no such thing as absolute time so the distinction you're trying to make is not clear.
- langcss 2y ago
  Most use cases don't care about relativity
SoftTalker 2y ago
And even then it's difficult. Time zone definitions change. Summer time does not start and end on the same date everywhere. So you also might need to know the UTC offset corresponding to the time zone at that time not just the UTC offset of that time zone today (assuming it still exists) Edit to add: still, this sounds like a great improvement. A common mistake that naive programmers make is to believe that they can hand-roll their own date/time functions. And JavaScript sort of forces them to do that. See also Falsehoods programmers believe about time at https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...
- treflop 2y ago
  It’s not difficult if you understand what you are trying to do conceptually. For example, if you are trying to say “run this task at this specific time in Los Angeles time” and you put a specific UTC offset, it just doesn’t make any sense. Los Angeles time consists of two offsets, and yet here you openly put down something wrong. You need to put into your system literally Los Angeles time (like America/Los_Angeles) because that’s what you want. You didn’t want an offset. Dear god why are you putting an offset then? Or you want to define a specific date but then you put into your system a date with a time like 12/12/2024 00:00. Like you started off with “I want to define a specific date” and here you openly just put a time. You had to make up 00:00. Why are you just doing random things without thinking?
  - SoftTalker 2y ago
    I wasn't literally suggesting that you store offsets. Or timestamps. There are way too many weird cases around doing that. But "America/Los_Angeles" is a reference to a file in tzfile(5) format, which contains, among other things, the UTC offset. And a function that produces the correct date and time in Los Angeles at any point in the past has to know (among other things) if that offset was ever anything different, and if it was, when it changed. And many other things. There are date/time libraries that can't get all of this right, but you'll come a lot closer using them than you will rolling your own. Don't store raw timestamps. Don't store offsets. Use date/time data types.
namtab00 2y ago
In your support: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...

naasking 2y ago

There is no such thing as absolute time so the distinction you're trying to make is not clear.

langcss 2y ago
Most use cases don't care about relativity

SoftTalker 2y ago

And even then it's difficult. Time zone definitions change. Summer time does not start and end on the same date everywhere. So you also might need to know the UTC offset corresponding to the time zone at that time not just the UTC offset of that time zone today (assuming it still exists) Edit to add: still, this sounds like a great improvement. A common mistake that naive programmers make is to believe that they can hand-roll their own date/time functions. And JavaScript sort of forces them to do that. See also Falsehoods programmers believe about time at https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...

treflop 2y ago
It’s not difficult if you understand what you are trying to do conceptually. For example, if you are trying to say “run this task at this specific time in Los Angeles time” and you put a specific UTC offset, it just doesn’t make any sense. Los Angeles time consists of two offsets, and yet here you openly put down something wrong. You need to put into your system literally Los Angeles time (like America/Los_Angeles) because that’s what you want. You didn’t want an offset. Dear god why are you putting an offset then? Or you want to define a specific date but then you put into your system a date with a time like 12/12/2024 00:00. Like you started off with “I want to define a specific date” and here you openly just put a time. You had to make up 00:00. Why are you just doing random things without thinking?
- SoftTalker 2y ago
  I wasn't literally suggesting that you store offsets. Or timestamps. There are way too many weird cases around doing that. But "America/Los_Angeles" is a reference to a file in tzfile(5) format, which contains, among other things, the UTC offset. And a function that produces the correct date and time in Los Angeles at any point in the past has to know (among other things) if that offset was ever anything different, and if it was, when it changed. And many other things. There are date/time libraries that can't get all of this right, but you'll come a lot closer using them than you will rolling your own. Don't store raw timestamps. Don't store offsets. Use date/time data types.

namtab00 2y ago

In your support: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...