I like how Temporal[0] does this. What you were dealing with is Temporal.PlainDate[1], i.e. 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).

Temporal has other cool types, each with distinct semantics:

- 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.

- 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.

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

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

- 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.

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

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

- Duration: think e.g. "the task ran for 3hrs 30min".

Also see its important concepts[2].

[0] https://tc39.es/proposal-temporal/docs/

[1] https://tc39.es/proposal-temporal/docs/#Temporal-PlainDate

[2] https://tc39.es/proposal-temporal/docs/timezone.html

▲

Terr_ 4 days ago | parent | next [-]

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 )

▲

keeganpoppen 5 days ago | parent | prev | next [-]

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.

	▲	benreesman 5 days ago \| parent [-]
		Relatedly, std::chrono isnt exactly a beauty, but it did get people thinking about time points and durations and clocks and which operations are valid ways to move among them. Stuff like this is good.

▲

geocar 4 days ago | parent | prev [-]

> 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.

▲

kaoD 4 days ago | parent [-]

Just FYI you were downvoted with no explanation because you missed the point in all of these and you're using a smug and off-putting tone which makes it look like only care about "being right" and not finding what "is right".

Also you obviously didn't bother reading the "important concepts" link ([3]).

I was going to assume good faith and reply to each of your comments but it'd probably be a waste of time. As a summary: most of your concerns are wrong due to (1) confusing "timezones" with "location" or "internationalization" (2) confusing internal representations (like Epochs) with what these objects represent as described in the "important concepts" link and (3) just being completely wrong like saying you cannot do reasonable arithmetic with PlainMonthDay or even understand that not every relevant operation is arithmetic (good luck calling `.toPlainDate(2025)` with your string representation).

▲

geocar 3 days ago | parent [-]

> FYI you were downvoted with no explanation because you missed the point in all of these

I think people downvote things they disagree with, and I'm not surprised people who think handling dates and times is beyond them are mad at someone exists who doesn't, because I'm calling out their impotence in a way.

And I understand you don't want to feel impotent, so telling me that you're not going to respond to me is a way for you to reclaim some of that.

> just being completely wrong like saying you cannot do reasonable arithmetic with PlainMonthDay

Then prove it: How exactly do you think you can meaningfully add two PlainMonthDays? What does such a thing mean?

I think you don't know what you are talking about, and you somehow think that means I don't either.

▲

kaoD 3 days ago | parent [-]

> Then prove it: How exactly do you think you can meaningfully add two PlainMonthDays? What does such a thing mean?

Star Wars day is May the 4th. Today is May the 1st. Star Wars day is in 3 days.

I'll stop here.

▲

geocar 3 days ago | parent [-]

You might want to look in a dictionary and see what `add` means.

4May+1May is still not meaningful to me, and frankly I do not believe that it is meaningful to you. I do not think you have thought about what I am saying at all, and think it's shocking that you have an opinion about something you clearly don't understand.

▲

pavo-etc 2 days ago | parent [-]

You might want to look in a dictionary and see what `subtract` means.

4May-1May is meaningful to me, and frankly I do believe that it is meaningful to you. I do not think you have thought about what we are saying at all, and think it's shocking that you have an opinion about something you clearly don't understand.

	▲	geocar 2 days ago \| parent [-]
		> 4May-1May is meaningful to me Great, but it isn't addition. > and frankly I do believe that it is meaningful to you. Well you're wrong. Consider 1Mar-28Feb: Should this be 1 or 2? This proves it can't be subtraction (in the arithmetic sense) either. > You might want to look in a dictionary and see what `subtract` means. Subtraction is only addition if 4May-1May is equivalent to 4May+-1May which leaves you with an additional problem: What to do about negative plaindates. > I do not think you have thought about what we are saying at all I've probably thought about it too much at this point. You don't even know how arithmetic works, so I think if you have anything to say it will be too difficult for me to understand.