Calabrese, Christopher <[EMAIL PROTECTED]> writes:
> Huh? 11 digits worth of seconds takes you out to 5138, and there's
> nothing here that limits the number of digits (I was just pointing out
> that you'll use less than 11 digits for the foreseeable future - in fact
> 10 digits gets you to 2286). Yes, you'll need a 64-bit machine/OS to do
> the conversion easily starting in 2038, but that's certainly better than
> creating a protocol that requires a 64-bit machine today.
I'm really not sure where you're getting this from... 32-bit machines are
perfectly capable of manipulating 64- or even 128-bit timestamps with very
little difficulty. Just deal with them in 32-bit chunks. This just isn't
that much code.
Please don't send timestamps in formats other than seconds-since-epoch on
the wire. Otherwise, you just make it unnecessarily difficult for systems
that need to merge logs by timestamp from multiple sources, for little
gain. So many protocols and file formats already use seconds-since-epoch
that one gets used to doing the conversion; with Perl, it's even a
one-line shell alias. And it's obviously reasonable to convert to a
human-readable time for logging (and quite easy).
Converting from ASCII to a number requires doing string parsing, which I
think should generally be avoided unless it's necessary for some reason.
I don't see the need here.
--
Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
