5 ms·

It's not just that. Timezones are the real bugger. Microsoft has their own list of names separate from the standard IANA timezones, for example. If it weren't f

It's not just that. Timezones are the real bugger. Microsoft has their own list of names separate from the standard IANA timezones, for example. If it weren't for timezones, IMO dates are pretty damn trivial. It's just a matter of storing and transferring them properly (in UTC, always!)

frenchyatwork 6y ago
Timestamps are damn trivial. When people use dates, that's all they want 90% of the time. The remaining 10% is where all the hard problems are. For example, lets say I have a store that opens from 8:00-17:00 every day, and it's currently 22:00. How long is it till it opens next?
- noja 6y ago
  Three days and an hour more than you think, because it's the weekend, and an extra day because the public holiday for tomorrow may or not be a working day. Oh and there was a timezone change.
  - bonedangle 6y ago
    And it's December 31st.. Still shocked by how many times I see a year rollover go bad.
    - unilynx 6y ago
      Even before the rollover it get's bad. I had a CI failure on 31 December 2018 for code which worked fine on 31 December 2017, because it was the first time for that code to have Dec 31 in week 1 of the next year. And last year someone else's code failed on 30 December 2019, so I had a pretty good idea where to look. Still need to fix a bug in code written only yesteryear because the 1st of July wasn't on a Monday this year, but I decided to snooze that test failure ... it'll work fine again in 9 years.
  - aarong11 6y ago
    There was a leap second too, you forgot that one!
    - timgilbert 6y ago
      ...oh, and I hope you know whether your customer is Israeli or Palestinian! https://www.972mag.com/the-worlds-only-ethnic-time-zone/ https://www.972mag.com/the-worlds-only-ethnic-time-zone/
    - reggieband 6y ago
      People joke, but I worked on a calendar application (well, it was a time series graph) where a leap second caused a rendering bug.
      - yxhuvud 6y ago
        There was this bug in Java related to a leap second that broke all Java servers in the world one summer..
  - deleted 6y ago
    [deleted]
- mad182 6y ago
  You forgot there will be a leap second and switch to summer time.
- other_herbert 6y ago
  This is a case for events! The store opens when the owner unlocks the door..... but since you are in that nebulous time when it is "closed" the next "open" may never happen.. so maybe what really needs to happen is a giant disclaimer around times for things... like in your search results for let's say some M-F 8-5 business... it would say "Hours: 8:00-17:00, Closed right now, in 72% of the cases, the next opening time is tomorrow morning at 8"
- jniedrauer 6y ago
  I recently did this for a task scheduler. The logic lives in SQL. That was a "fun" query to write... You might think it's the wrong tool for the job, but it was a lot faster than reading every possible row and checking it in the application itself.
- smichel17 6y ago
  As a shortcut for coming up with the corner cases yourselves, this document has a good list of them: https://moment.github.io/luxon/docs/manual/math.html https://moment.github.io/luxon/docs/manual/math.html
- tigershark 6y ago
  No, they are not trivial at all as I explained in my previous comment. For more sauce: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/amp/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a... About your question it’s impossible to answer without further context. There may be DST tonight, or a leap second, or the enforcement of some strange treaty that will change the time zone..
1-more 6y ago
There is a case to not store a time in UTC: you schedule a meeting in the future and the local authorities change when they start DST in that location. Now your user gets the alert an hour too early or late for their meeting. The scenario is more fleshed out in the link below but I don't want to just copy and paste the article into the comment. http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html http://www.creativedeletion.com/2015/03/19/persisting_future...
deathanatos 6y ago
> in UTC, always! … which the proposal doesn't use. (It uses POSIX.)
tigershark 6y ago
No they are absolutely not. Ask Jon Skeet for example: https://codeblog.jonskeet.uk/2010/12/01/the-joys-of-date-time-arithmetic/amp/ https://codeblog.jonskeet.uk/2010/12/01/the-joys-of-date-tim... https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/amp/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a... Or look at the usual falsehood list: https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b... Some interesting ones: A week (or a month) always begins and ends in the same year. Months have either 28, 29, 30, or 31 days. There is a leap year every year divisible by 4. The day before Saturday is always Friday.

frenchyatwork 6y ago

Timestamps are damn trivial. When people use dates, that's all they want 90% of the time. The remaining 10% is where all the hard problems are. For example, lets say I have a store that opens from 8:00-17:00 every day, and it's currently 22:00. How long is it till it opens next?

noja 6y ago
Three days and an hour more than you think, because it's the weekend, and an extra day because the public holiday for tomorrow may or not be a working day. Oh and there was a timezone change.
- bonedangle 6y ago
  And it's December 31st.. Still shocked by how many times I see a year rollover go bad.
  - unilynx 6y ago
    Even before the rollover it get's bad. I had a CI failure on 31 December 2018 for code which worked fine on 31 December 2017, because it was the first time for that code to have Dec 31 in week 1 of the next year. And last year someone else's code failed on 30 December 2019, so I had a pretty good idea where to look. Still need to fix a bug in code written only yesteryear because the 1st of July wasn't on a Monday this year, but I decided to snooze that test failure ... it'll work fine again in 9 years.
- aarong11 6y ago
  There was a leap second too, you forgot that one!
  - timgilbert 6y ago
    ...oh, and I hope you know whether your customer is Israeli or Palestinian! https://www.972mag.com/the-worlds-only-ethnic-time-zone/ https://www.972mag.com/the-worlds-only-ethnic-time-zone/
  - reggieband 6y ago
    People joke, but I worked on a calendar application (well, it was a time series graph) where a leap second caused a rendering bug.
    - yxhuvud 6y ago
      There was this bug in Java related to a leap second that broke all Java servers in the world one summer..
- deleted 6y ago
  [deleted]
mad182 6y ago
You forgot there will be a leap second and switch to summer time.
other_herbert 6y ago
This is a case for events! The store opens when the owner unlocks the door..... but since you are in that nebulous time when it is "closed" the next "open" may never happen.. so maybe what really needs to happen is a giant disclaimer around times for things... like in your search results for let's say some M-F 8-5 business... it would say "Hours: 8:00-17:00, Closed right now, in 72% of the cases, the next opening time is tomorrow morning at 8"
jniedrauer 6y ago
I recently did this for a task scheduler. The logic lives in SQL. That was a "fun" query to write... You might think it's the wrong tool for the job, but it was a lot faster than reading every possible row and checking it in the application itself.
smichel17 6y ago
As a shortcut for coming up with the corner cases yourselves, this document has a good list of them: https://moment.github.io/luxon/docs/manual/math.html https://moment.github.io/luxon/docs/manual/math.html
tigershark 6y ago
No, they are not trivial at all as I explained in my previous comment. For more sauce: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/amp/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a... About your question it’s impossible to answer without further context. There may be DST tonight, or a leap second, or the enforcement of some strange treaty that will change the time zone..

1-more 6y ago

There is a case to not store a time in UTC: you schedule a meeting in the future and the local authorities change when they start DST in that location. Now your user gets the alert an hour too early or late for their meeting. The scenario is more fleshed out in the link below but I don't want to just copy and paste the article into the comment. http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html http://www.creativedeletion.com/2015/03/19/persisting_future...

deathanatos 6y ago

> in UTC, always! … which the proposal doesn't use. (It uses POSIX.)

tigershark 6y ago

No they are absolutely not. Ask Jon Skeet for example: https://codeblog.jonskeet.uk/2010/12/01/the-joys-of-date-time-arithmetic/amp/ https://codeblog.jonskeet.uk/2010/12/01/the-joys-of-date-tim... https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/amp/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a... Or look at the usual falsehood list: https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b... Some interesting ones: A week (or a month) always begins and ends in the same year. Months have either 28, 29, 30, or 31 days. There is a leap year every year divisible by 4. The day before Saturday is always Friday.