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.
depends how important it is. app for tracking celebrity hairstyles forego precision for easy understanding, stock markets precision needed.
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.
The AI-specific use of em dash with the list of three near-synonyms following, the "it's not just this", the "it's a fundamental shift". This article seems AI-generated or at the very least AI-massaged.
Once you suspect AI has been used to write something, you're not sure if the 'author' has bothered to double-check the article for veracity, or if you're going to be doing this work for them.
It's terrible.
> The truth: your current date system isn’t just awkward — it’s wrong. We fixed it. And if that feels unsettling… maybe it’s time your code grew up.
Whoever wrote this (whether carbon or silicon; I lean toward the latter) ... should find another line of work.
It’s this. The current crop of LLMs have latched onto a small number of mannerisms that they constantly overuse, along with a weird TEDx voice and belief that everything is game-changing. It wasn’t so bad until recently, but it’s gotten so much worse lately – the overuse of these things would practically be a verbal tic if a human used them so often.
It’s incredibly tiring to read, especially as it uses so many words to say so little. Take this for instance:
> it’s a fundamental shift in how your software thinks.
This is pure, unmitigated horseshit. We’re talking about date representation not a major paradigm shift. But LLMs spit out this crap all the time. It’s not saying anything, it’s just putting one word in front of another.
The human who publishes this should be reviewing it to catch it when it goes off the rails like this, but it seems like it was published with no human oversight at all, or at least none that is able to catch it talking nonsense.
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.
pgte•6mo ago
re•5mo 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...
windock•5mo ago