[krylon]

> Unix time can represent roughly from 1902 to 2038 in 32 bits.

Uh, several systems have already switched to a 64 bit timestamp that should last for a while. I am relatively certain that OpenBSD and NetBSD have done it, and I vaguely remember Linux doing that, too, but that might be a vague memory or wishful thinking. Other systems probably have switched, too.

[logfromblammo]

That's fine; better than nothing. It still represents times within the span of human history as negative numbers, which sometimes leads to certain kinds of bugs.

Ideally, I'd never have to work with a negative date-time number, because someone always seems to want to check if t > 0 somewhere, and there's always a reason why t could plausibly be a valid negative. Or maybe someone picked some negative t as a sentinel value, and then left the company before I ever got a chance to slap them.

Julian Day is the only kind of time that has never insulted my delicate sensibilities in some way. Maybe that's intrinsic to the type, or maybe it's because those who chose to use it have never done stupid things with time (that I could see).

[krylon]

I get your point.

Most of the time (pun not intended), I do not need to worry about the time or date. But on a few occasions I had to, and it gave me a headache every time.

One time (again, pun not intended!), I helped one of our automation engineers who had somehow found out that I know the C programming language and asked me to help him with a problem he was facing: He wanted/needed an input gadget that would allow a worker at the customer site to schedule the cleaning process of the automated machinery in terms of "tomorrow at 3:15am". And then a process had to calculate how far that moment was in the future, sleep for the corresponding duration, then wake up and the the machines to get clean. Except that it had to work across the beginning and ending of DST. Which was not super hard in itself, you either add or subtract an hour from/to the duration you wait, but how do we figure out when the change between DST and normal time occurs? Well, turns out in Germany[0] DST begins on the last Sunday in March at 03:00am (the clock is set to 02:00am) and ends on the last Sunday in October at 02:00am (the clock is set to 03:00am). If all you have is the C standard library (C89!), figuring out if it is the last Sunday of a certain month is surprisingly annoying. Not difficult, but very, very tedious. That made me appreciate the simplicity of C's time_t like no other experience in my life. And I just scratched the tip of the iceberg, with nail file. I can imagine how much fun it gets when different timezones come into play, or divergent definitions of when DST begins and ends.

Your idea of Julian day + millisecond offset sounds beautiful. But I fear it will meet the same enthusiasm as my proposal to convert the metric system from 10^3 to 2^10, i.e. make one kilogram 1024 grams, a metric ton would be 1048576 gram, and so forth.

[0] And probably a lot of other places, but not all of them, because then it would be sorta-kinda consistent, and we cannot have any of that.