-={ 2021-04-14 15:57:11.900772548+00:00 }=-
Hey August!
AA> I thought you said that your 32bit algorithm for the time-
AA> version took into account fractions of a second down to the
AA> microsecond/nanosecond.
That is impossible and if I did say that it would have been in conjunction with
the nanosecond part in order to facillitate that degree of resolution. The
later example I gave Wilfred would be of two 32-bit hex fields which would
resolve it to nanosecond output up to 2106 and then the seconds output would
output to 9 hex characters while the nanosecond part remains a 32-bit hex field
(fixed 8 hex character field). I recall saying that your idea is superior
since it doesn't require any changes to existing documentation regarding
MSGIDs.
If I gave you the wrong impression I will now apologize for my lousy
communication skills. I am obviously a lousy technical writer but in my
defence I never claimed to be good at it.
Please note the MSGID of this reply. I think it illustrates that I now have
and can facillitate both your idea as well as the usual 32-bit unixtime 8
character hex field which is in seconds not nanoseconds. Once 2106 rears it's
ugly head there is nothing in my routine that will prevent it from adding an
extra hex character but then it won't be compliant to the current documented
MSGID/REPLY format. However the routine based on random 8 character [:alnum:]
regex should still be good to go if indeed my attempt at forwards compatibilty
fails, which according to everyone is the most likely result. I am on record
saying that I am prepared to soldier on if indeed that happens. That won't
stop me from trying again in the future but I cannot guarentee how long I can
keep soldiering on. I am getting old.
Life is good,
Maurice
... Ich habe Eichh├╢rnchen in meiner Hose!
--- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
|
