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?

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.

And it's December 31st.. Still shocked by how many times I see a year rollover go bad.

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.

There was a leap second too, you forgot that one!

...oh, and I hope you know whether your customer is Israeli or Palestinian!

https://www.972mag.com/the-worlds-only-ethnic-time-zone/

People joke, but I worked on a calendar application (well, it was a time series graph) where a leap second caused a rendering bug.

There was this bug in Java related to a leap second that broke all Java servers in the world one summer..

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...

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..

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"

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

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.

You forgot there will be a leap second and switch to summer time.

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...

No they are absolutely not. Ask Jon Skeet for example:

https://codeblog.jonskeet.uk/2010/12/01/the-joys-of-date-tim...

https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...

Or look at the usual falsehood list:

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.

> in UTC, always!

… which the proposal doesn't use. (It uses POSIX.)