I hope that as time goes on software design get better about modeling things that are guesses, conjecture, etc. rather than Absolute Facts.

As-is, we assume lots of things are facts and we just hope it's true enough to avoid problems. (Starting with the business requirements. :p )

yeah, it was a long (and painful) time coming, but i think the temporal api finally basically nailed it. you know a library is good when you learn something about how to think about the problem just from how the code/api is structured.

> a date with a calendar associated but no time or timezone (might be due to being implied but also might be irrelevant, like in birthdates).

It might also be relevant: Ever ask an older Korean person their age?

> Instant: a fixed point in time with no calendar or location. Think e.g. "the user logged in at X date and time" but valid across the world for any timezone or calendar system. This is what we usually use "Unix UTC timestamps" for.

This is not a thing. Those are intervals to some Epoch, maybe taking into account leap-seconds and maybe not. They are not very useful except grossly over long ranges.

> - ZonedDateTime: like an Instant but associated with a particular calendar and location. Think an Instant but rendered "real" into a calendar system and timezone so the user can see a meaningful time for them.

Like when a user logged in at X date and time. They don't do this from no location, but from some location.

> - PlainDate: already discussed. Think e.g. birthdates.

And already wrong.

> - PlainTime: think "run task every day at 6:30pm".

Erm no. You can say 18:30 hours after midnight, or you can say when the calendar says 6:30pm, but these are different things. Imagine the poor fool who wants to run the task every day at "1:30am" and has it run twice on some days.

Bars close in some parts of the world at 30h (30時) to mean 6am the following day.

> - PlainDateTime: like an Instant but associated with a calendar system, but no timezone. Think e.g. what a user would insert in a datetime picker, where the timezone is implied instead of explicitly selected.

No, like a string.

> - PlainYearMonth: think e.g. "we'll run our reports during October 2025".

Nonsense. Also a string.

> - PlainMonthDay: think e.g. "my birthday is June 13".

Your birthday might be on the 29th of January. You cannot do reasonable arithmetic with such things, so it might as well be a string like many of these others.

> I like how Temporal[0] does this.

I don't if you can't tell. This stuff is complicated and I'd like more people exploring it because I don't know The Right Answer™ either, but I know enough to know that every existing solution is wrong in some way that can cause real harm.

Furthermore, require dashes over slashes to signal that you are expecting ISO-8601 compatible dates, i.e., YYYY-MM-DD. Most users does not know the standard even exists, but it serves as an affordance that it is different from dd/mm/yyyy, etc.

Every time I see an input date string in XX/XX/YYYY format I get a micro PTSD flashback. This cannot be parsed reliably and is locale dependent. The standard date format is YYYY-MM-DD (it's also the date part of the ISO time format). Raw text inputs should be avoided as much as possible, date/time pickers should be preferred.

This isn't really relevant to the parent's topic though, aside from UX. The UI can tell the user which is the day and which is the month. The logic layer knows the format explicitly.

Pretty sure they force the user into that format so that shouldn't be an issue

They may have something that's just not as easy to work with as strings. E.g. in Swift, you have DateComponents, but that's too dynamic (and Date is sometimes referred to as naive, but that's a misunderstanding, since they are timestamps, not date+time).

Javascript/swift/kotlin frontend, python backend, mysql server. The problem wasn’t that I had access to zero (presumably) well implemented time abstractions with all the bells and whistles, it was that I had five well implemented native time abstractions.

The dose varies per age, but this isn't that exact.

No, don't do that. Use a date datatype (not date/time). You aren't the first person to ever need to handle dates without times/timezones in a computer program. Use what your database/language/libraries already have to support that.

In my humble opinion, this is not good advice unless you demonstrably need it for query performance or something. It is very easy for the logic layer to accidentally mess that up, either in reading or, worse, in writing back.

In this case, I'd suggest storing what you mean (the user wasn't born 9,487 days after Jan 1 1970. They were born Dec 23, 1995.)

Storing the literal units (and ONLY the relevant units), as the parent has, is robust and logically+semantically correct (they could add a translation layer for UX so the user doesn't have to be particular, but that's beside the point). Whether you use a string or a struct or some date-only type is moot, as long as you're literally storing the year, month, and day, and only those three things. You can ephemerally convert it to your platform's date type if you need to.

> The translation from/to this representation to a broken-down y/m/d takes only ~50 lines of code anyways.

Didn't the article explicitly tell us not to write our own date parsing library?

> or my favorite January 1, 1600 since 1600 is a multiple of 400

You need to deal with 1600 and 2000 being leap year.

While 1700, 1800, 1900 not being a leap year.

I limit dates from 1900 to 2100. All !year%4 = leap year.

Especially when you try to convert int_date to y,m,d things get tricky.

I always find that a little annoying: it takes way too many clicks (esp. for a birth year) and then you've got to find the day of the week.

I'd hate it less if typing updated the widget.

I've had to click back once per year old I am sometimes. I'd rather just type my birthday.