Subj : anyway the wind blows To : August Abolins From : Maurice Kinal Date : Wed Apr 14 2021 15:57:11 -={ 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) .