Hacker News Reader

Comment by frenchyatwork | Hacker News Reader

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?

View on HN

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.

Reply on news.ycombinator.com