Re: Represent NTP's origin time

[Achim Gratz <Stromeko@nexgo.de>]

tomas@tuxteam.de writes:
> Again. The fact that *you* haven't doesn't mean that others are
> in the same boat. A maintainer's job involves exactly that kind
> of deliberation :)

You are tilting at windmills.

> (I'd bet that Stefan's hardware is still 32 bit :)

The hardware is probably not, but it wasn't explicitly mentioned.  The
hardware isn't the issue here anyway.  The implementation of time_t is,
as was clear from the original posting and later confirmed to be the
case.

> So basically it reduces to whether the Emacs project wants to
> support 32 bit systems (currently, the answer seems to be "yes")
> and what to do about time_t when yes.

No, that was not the question Stefan originally asked, but one that you
brought into the discussion.  To be clear, I have not and I will not
offer an opinion on that particular topic in this thread.

The question of Stefan was how to represent the NTP epoch (or "origin
time") and the answer was and still is you can't do that on a system
that has 32bit time_t of any kind.  The question of whether you'd want
to support Emacs on such systems is immaterial to both the question and
the answer.

The workaround that was mentioned multiple times now works for
conversion between NTP to UNIX representation (both ways) without the
need to have an explicit representation of the NTP epoch, with the
disadvantage that it only works where those two representations overlap
(i.e you lose about two years on either end).  But that is the answer to
an extrapolation of the original question which Stefan revealed later as
the actual problem he wanted to solve.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada