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.
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.
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
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.
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
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.
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 don’t think this is related to AI at all. (Unless you’re suggesting it’s AI-generated?) It’s “thinking” as a metaphor for the abstraction being used.
chao-|6 months ago
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.
OptionOfT|6 months ago
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.
bryanrasmussen|6 months ago
depends how important it is. app for tracking celebrity hairstyles forego precision for easy understanding, stock markets precision needed.
flufluflufluffy|6 months ago
Humphrey|6 months ago
Eg, in Python
year = int
month = str (yyyy-mm)
day = naive date
exact moment = timezone aware datetime
rich_sasha|6 months ago
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.
croisillon|6 months ago
01HNNWZ0MV43FF|6 months ago
What day is it at 23:59:59.500 then?
You're wrong about intervals! </jk only serious>
gmokki|6 months ago
zvr|6 months ago
alextingle|6 months ago
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.
jillesvangurp|6 months ago
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.
torium|6 months ago
For example, this lib makes the assumption that years and months have a fixed length, e.g. date(2024Q2) - date(2024Q1) = 3 months
JimDabell|6 months ago
I’m sorry, I just can’t get past this awful hyperbolic AI drivel.
ksenzee|6 months ago
pgte|6 months ago
re|6 months ago
I 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...