You're Wrong About Dates – and Your Code Is Lying to You
1–10 of 22 posts
Re: You're Wrong About Dates – and Your Code Is Lying to You
#2Why your mental model of dates is broken, how programming languages gaslight us about time, and how Decipad’s interval-based approach fixes it.
Re: You're Wrong About Dates – and Your Code Is Lying to You
#3it'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
Re: You're Wrong About Dates – and Your Code Is Lying to You
#4I forget where I first heard it, but "Dates are not real. Only times with zones are real."
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.
Re: You're Wrong About Dates – and Your Code Is Lying to You
#5> midnight to 23:59:59 that day.
What day is it at 23:59:59.500 then?
You're wrong about intervals!
Re: You're Wrong About Dates – and Your Code Is Lying to You
#6> This isn’t just “nicer syntax” — it’s a fundamental shift in how your software thinks.
I’m sorry, I just can’t get past this awful hyperbolic AI drivel.
Re: You're Wrong About Dates – and Your Code Is Lying to You
#7Where 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.
Re: You're Wrong About Dates – and Your Code Is Lying to You
#8> This isn’t just “nicer syntax” — it’s a fundamental shift in how your software thinks . I’m sorry, I just can’t get past this awful hyperbolic AI drivel.
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.
Re: You're Wrong About Dates – and Your Code Is Lying to You
#9Meh. People know dates are intervals. You just have to use it properly. All libs make assumptions.
For example, this lib makes the assumption that years and months have a fixed length, e.g. date(2024Q2) - date(2024Q1) = 3 months
Re: You're Wrong About Dates – and Your Code Is Lying to You
#10I'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
Eg, in Python
year = int
month = str (yyyy-mm)
day = naive date
exact moment = timezone aware datetime