Re: "A diagram of C23 basic types"

On 4/16/2025 3:04 PM, Scott Lurndal wrote:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote at 23:42 this Tuesday (GMT):

[...]

The epoch is a specified moment in time.  That moment can be
expressed as midnight UTC Jan 1 1970, as 4PM PST Dec 31 1969,
or (time_t)0.  GMT/UTC is just a convenient way to specify it.

>
You could also be GoLang and use MST January 2 2006 at 3:04:05 PM.
(1/2 03:04:05 PM 2006 GMT-7)

>
That's not an epoch.  It's a reference time used in documentation,
chosen because all the fields have unique values.  It means that results
of converting a time to the dozen or so supported layouts can be easily
read.
>
[...]
>

Datetime is a nightmare, this is why we use a simple seconds-since-X
system.

>
Indeed.  That makes it a slightly less unpleasant nightmare.

 Back in the mainframe days, it was common to use julian dates
as they were both concise (5 BCD digits/20 bits) and sortable.
    YYDDD
 If time was neeeded, it was seconds since midnight in a reference
timezone.

One shorthand is to assume a year is 365.25 days (31557600 seconds), and then base everything else off this (initially ignoring things like leap-years, etc, just assume that the number of days per year is fractional).
Then, say, 2629800 seconds per month, ...
For some other calculations, one can assume an integer number of days (365), just that each day is 0.07% longer.
For date/time calculations, one could then "guess" the date, and jitter it back/forth as needed until it was consistent with the calendar math.
Estimate and subtract the year, estimate and subtract the month, then the day. Then if we have landed on the wrong day, adjust until it fits.
Not really sure if there was a more standard way to do this.
A few times, I had hypothetically considered a non-standard power-of-2 year:
   2^25 seconds per year (or, about 6% longer than a standard year).
Didn't come up with a calendar for this.
Choice is 256 days, each 50% longer, or 512 days, each around 76% as long. Or, allow non-power-of-two here, 384 days (each day is 1% longer, 32 days per month). Though, if each "hour" is 4096 seconds, 14% longer (with 64 seconds per minute), the hour+day can be recombined to a 13 bit field (so, overall, back to power-of-2, though without an integer number of hours per day).
Merit of such a calendar would be that date/time calculations would not require general case multiply or divide.
Downside is, well, that it has no real correlation to the actual calendar.
And, if used as a first order guess for standard calendar conversion, would likely end up slower than just using divide (as it would likely have to work harder to jitter things to the correct date).
As for time since epoch:
Microseconds (in a power-of-10 sense) are more common...
Though, possibly, someone could make a case for using a power-of-2 fraction (2^20), or around 954ns per tick.
Maybe a 24 bit fraction could also make sense, say:
   So, each tick is 59.6ns.
A 64 bit value here could express a time span of around +/- 16k years (still more than enough for the foreseeable future).
...