@MSGID: 1:266/625 6a2566dc
@REPLY: 1:153/7001.64222 18b6a54b6e32fa05
@TZUTC: -0400
@PID: msged/lnx 6.3 2023-02-24
@TID: hpt/lnx 1.9 2024-03-02
 >> @MSGID: 1:266/625 6a2458e9f2b1d9e9

 MK> A 64-bit nanosecond unixtime?  If so you`ve convinced me to follow 
 MK> suit on my new experimental point. 


 Well, not exactly; two values where computed and squished together,
it really is: (unix time 32b)6a2458e9 (msg CRC32)f2b1d9e9

 Though, it appears I read the spec and missed the fact that the
serialno is only supposed to be 8 characters (which means 32b in hex). So
I`ve got to rethink the MSGID generation.

 MK> Welcome to the 21st century ... just shy of 26 years too late.  Oh 
 MK> well, no time like the present eh?

 We`ve got a few years before the unsigned 32 int runs out of
space for the current time. JAM uses a uint32_t for time. It needs to
be a uint64_t soon, before Feb 7, 2106. One of the things on my back
burner is to upgrade JAM`s format for uint64 dates. I`m on the fence
about making the storage pointers 64b, the 32b ones will still address
4Gb in a file and 4.2 million messages in a given message base. (64b
file index could address 18billion terabytes -- which, according to
Google, is more storage on all the planet.)

--- 
 * Origin: <=-[ The Digital Post ]-=> (1:266/625)
SEEN-BY: 18/200 50/13 279 103/705 105/81 106/201
114/201 124/5009 5016
SEEN-BY: 128/187 129/12 14 102 125 160 165 305
328 153/757 7715 154/10 30 110
SEEN-BY: 203/0 218/700 221/0 226/30 227/114 229/110
112 206 300 317 400 426
SEEN-BY: 229/428 470 616 664 700 705 240/1120
5832 261/1 263/1 266/75 325 512
SEEN-BY: 266/618 625 630 267/152 154 280/464 1043
5003 291/111 292/854 8125
SEEN-BY: 301/1 310/31 320/219 322/757 341/66 234
342/200 396/45 423/120
SEEN-BY: 460/58 633/267 280 712/620 730 848 770/1
902/26 5020/400 545 848
SEEN-BY: 5020/1042 1477 4441 12000 5025/3 75
5030/1081 1957 2404 5037/7
SEEN-BY: 5053/58 5060/900 5066/18 5075/35 5080/102
5095/20 6078/80
@PATH: 266/625 512 229/426 712/848 280/464 5020/545
4441