> unncessary artificial complexities

The very fact they are there, still used, and so on, contradicts "unnessary [sic]". Sure, it might be outdated now, or technically better alternatives might be there.

But, in the end, software that deals with "The Real World" is going to be a complex, illogical mess. Because the real world is a complex, illogical mess. We could make a time that is global, counts resonant frequency of atoms. While technically superior, I will continue saying "The job took me 3h25 minutes" and not "The job took me 113,066,170,771,000,000 cycles", or even "The job took me 113066 Tera-cycles." or such. Messy, illogical and complex is often simply more practical. If only because "everyone does it that way".

And we're going to say "let's do this a day from now", leaving the software to decide whether that's 24, 23 or 25 hours from now. It could be any of those things, depending on where it was said and the DST changes for that timezone.

Or conversely, is a specified instant considered "tomorrow"?

I generally consider "tomorrow" to be an interval and not an instant. It is ambigous how large of an interval it is and how far in the future it begins.

"tomorrow" in the real world is also surprisingly complex.

I once built a calendar and reservation system for a theatre that did movies, theatre, concerts and parties. A party that starts Friday at 22:00 and ends at 1:30 doesn't end "tomorrow" in people's minds, it ends Friday night.

(And a party, concert or movie that technically starts Sunday, 00:15 still has to show up on Saturday night 00:15, because that's how everyone looks for it)

"Tomorrow" is an interval. I meant to say, is a specified instant within the "tomorrow" interval?

Why don't we standardize on kilosecs and megasecs!?

Time library can be simple, it's just rust libraries tend to be philosophic for some reason, but it's only one of many design approaches.

They can certainly be simple and incomplete, or simple and incorrect; do you have an example of a simple, complete, and correct time library?

You think your philosophy is stronger than any other philosophy? I mean it's philosophic design approach itself which is doubtful. Correctness is satisfaction of expectations. For any library there are expectations that it doesn't satisfy.

Is that relevant? If my philosophy is weak, you can prove it to be weak by providing me with an example of a library which conforms to a better philosophy; then I can see why it's better.

Everybody thinks their philosophy is the best. Take for example C89 time library. You'll just say it doesn't satisfy your philosophy.

I won't just say it doesn't satisfy my philosophy. I'll say additionally that the .NET standard library's `DateTime` type, which I believe is essentially the same and uses basically the same primitives, is so hard to use correctly that I have multiple times had to rewrite other people's programs, in one case completely from the ground up, to fix their correctness due to bugs I personally encountered in them in real life. I do have empirical evidence for some of my opinions, you know!

Time handling is one of the many cases where there is actually complexity in the domain, and if you refuse to model the complexity, that doesn't make the complexity go away; it just means you've got bugs.

I only saw DateTime.Now where StopWatch should be used and serialization inconsistency due to discrepancy in time zone database.

So it's famously difficult to write a correct date-time handling program, but my empirical observation is that it's considerably easier with a library like Noda Time which actually attempts to model some of the domain beyond "ticks since the epoch".

How noda prevents you from using utc instead of StopWatch?