Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    ASIAN_LINK    |    Not the kind that loves you long time    |    8,456 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 7,837 of 8,456    |
|    Maurice Kinal to August Abolins    |
|    anyway the wind blows    |
|    14 Apr 21 15:57:11    |
   
   REPLY: 2:221/1.58@fidonet ef69774c   
   MSGID: 1:153/7001 tmCYOYVw   
   CHRS: UTF-8 4   
   -={ 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)   
   SEEN-BY: 1/123 18/200 90/1 105/81 106/127 114/705 120/340 123/120   
   SEEN-BY: 123/131 124/5016 129/305 153/105 135 250 757 802 7001 154/10   
   SEEN-BY: 203/0 220/70 221/1 6 360 226/17 30 227/114 229/101 424 426   
   SEEN-BY: 229/452 664 700 1016 1017 230/0 240/5832 249/206 317 400   
   SEEN-BY: 250/5 8 261/38 267/800 280/464 5003 282/1038 288/100 292/8125   
   SEEN-BY: 298/25 301/1 305/3 310/31 317/3 322/757 335/364 340/1000   
   SEEN-BY: 342/17 200 396/45 423/81 120 460/58 633/280 712/848 770/1   
   SEEN-BY: 770/100 330 340 772/210 220 230 4500/1   
   PATH: 153/7001 757 221/6 1 280/464 770/1 317/3 229/426   
      
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca