it's an interesting feature, shame there is no immediate link to the product (and shame the article has been produced by AI) ; i've recently managed the relaunch of one product at work and some of the best user-friendly advances come from proper time understanding
You celebrate your birthday on January 5th, whether you're in Hawaii or New Zealand.
You might get texts from friends & family earlier and later than that.
Outlook had a funny bug where when you stored a birthday on a certain date (which is then an all-day event), it would shift that all-day event by x-hours when you changed timezones.
Where this stuff gets hard is time zones and localization. Add some daylight savings to the mix and you are going to get lots of subtle issues. These range checks only make sense in the context of localized dates. For example 2025 started almost a day earlier in Sydney then it did in LA.
And then there are cultural differences. Do weeks start on a Sunday or a Monday? People wielding different calendars (Chinese new year is not on the 1st of January). So what is the beginning of the year is dependent on where you are as well.
If you are not localizing your dates before doing the checks that the author is proposing, it's probably wrong. This stuff is complicated for good reasons.
Anyway, store UTC times. Deal with making it look pretty and culturally & geographically appropriate in your UI. You shouldn't have to update your database just because the user took a plane to the other side of the planet.
Anyway, intervals and range checks are pretty easy to do with decent libraries. I like Kotlin and Java's way of using Durations for arbitrary time intervals. Kotlin's version of that supports operators. And has useful extension functions. And a thing called LocalDate which is a date without the time part, exactly like the author proposes. There's also LocalDateRange, which you can use to represent intervals. There's no LocalDateTimeRange equivalent for that. But that's where you'd switch to instants and durations probably.
Relative date and time expressions are surprisingly hard. A little known feature in Elasticsearch is that somebody at some point hacked in a date math thing that allows you to specify "now-2d" and "now+7d" as a valid input for range queries on dates. Surprisingly hard to do more complicated expressions and parse them correctly. I had a go at that problem at some point. Cron parsers are tricky for the same reason. And there are a few dialects of that to add some features that people needed.
There's a rich history of people having tried a whole bunch of things with times and dates.
I've been working as a software dev for over 20 yrs and not really ever got caught in the precise moment issue that the author is talking about. You just need to pick the correct datatype for the kind of thing that you want. Eg
My mental model includes both precise moments and intervals. As does PHP’s native date/time functionality, which can do all the same things exemplified in the article. Stop telling me I’m wrong and that you’ve thought of something paradigm-shifting.
Even the example used on the blog post is wrong (in my timezone)...
Start = date(2020-02-23)
End = date(2020-04-05)
Duration = End - Start // 42 days
Duration as hours // 1008 hours
2020-03-29 was the start of Summer Time, so only 23 hours long. So the duration in question should be 1007 hours.
Having a span of time using days as the only unit is fine. But there no way to convert that into a different time unit without knowing which specific days we mean.
What happens if the duration concerns something that physically moves? Was the software running on a ship that travelled from Europe to Australia between February and April?
Honestly, gushing about how dumb everyone else is, without mentioning even basic wrinkles like this just screams Dunning Kruger.
The article clearly aims to be inflammatory, but I'd restate: dates and times are not the same. Ditto for time intervals etc. But lots of libraries skim over this, leading to terrible bugs.
Python date time library, for example, essentially has dates as low precision timestamps. If you subtract a second from a time at midnight, you get what you expect. But subtract it from a date and you are where you started.
You can't add 24hrs to a midnight timestamp to increment date by 1 because DST.
14 comments
[ 0.33 ms ] story [ 36.5 ms ] threadI feel like you haven't used most date libraries.
https://docs.oracle.com/javase/8/docs/api/java/time/YearMont... / https://docs.python.org/3/library/datetime.html#date-objects / https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
When you need to be precise, you specify a time and a zone.
When your application has users in different geographies, you need to be precise.
Displaying the date attached to a time is a presentational convenience. Only the time is real.
You celebrate your birthday on January 5th, whether you're in Hawaii or New Zealand.
You might get texts from friends & family earlier and later than that.
Outlook had a funny bug where when you stored a birthday on a certain date (which is then an all-day event), it would shift that all-day event by x-hours when you changed timezones.
What day is it at 23:59:59.500 then?
You're wrong about intervals! </jk only serious>
I’m sorry, I just can’t get past this awful hyperbolic AI drivel.
And then there are cultural differences. Do weeks start on a Sunday or a Monday? People wielding different calendars (Chinese new year is not on the 1st of January). So what is the beginning of the year is dependent on where you are as well.
If you are not localizing your dates before doing the checks that the author is proposing, it's probably wrong. This stuff is complicated for good reasons.
Anyway, store UTC times. Deal with making it look pretty and culturally & geographically appropriate in your UI. You shouldn't have to update your database just because the user took a plane to the other side of the planet.
Anyway, intervals and range checks are pretty easy to do with decent libraries. I like Kotlin and Java's way of using Durations for arbitrary time intervals. Kotlin's version of that supports operators. And has useful extension functions. And a thing called LocalDate which is a date without the time part, exactly like the author proposes. There's also LocalDateRange, which you can use to represent intervals. There's no LocalDateTimeRange equivalent for that. But that's where you'd switch to instants and durations probably.
Relative date and time expressions are surprisingly hard. A little known feature in Elasticsearch is that somebody at some point hacked in a date math thing that allows you to specify "now-2d" and "now+7d" as a valid input for range queries on dates. Surprisingly hard to do more complicated expressions and parse them correctly. I had a go at that problem at some point. Cron parsers are tricky for the same reason. And there are a few dialects of that to add some features that people needed.
There's a rich history of people having tried a whole bunch of things with times and dates.
For example, this lib makes the assumption that years and months have a fixed length, e.g. date(2024Q2) - date(2024Q1) = 3 months
Eg, in Python
year = int
month = str (yyyy-mm)
day = naive date
exact moment = timezone aware datetime
Even the example used on the blog post is wrong (in my timezone)...
Start = date(2020-02-23) End = date(2020-04-05)
Duration = End - Start // 42 days Duration as hours // 1008 hours
2020-03-29 was the start of Summer Time, so only 23 hours long. So the duration in question should be 1007 hours.
Having a span of time using days as the only unit is fine. But there no way to convert that into a different time unit without knowing which specific days we mean.
What happens if the duration concerns something that physically moves? Was the software running on a ship that travelled from Europe to Australia between February and April?
Honestly, gushing about how dumb everyone else is, without mentioning even basic wrinkles like this just screams Dunning Kruger.
Python date time library, for example, essentially has dates as low precision timestamps. If you subtract a second from a time at midnight, you get what you expect. But subtract it from a date and you are where you started.
You can't add 24hrs to a midnight timestamp to increment date by 1 because DST.
Etc etc.