home bbs files messages ]

Just a sample of the Echomail archive

Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.

   SYNCHRONET      Rob Swindell fetishistic worship forum      43,341 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 40,887 of 43,341   
   deon to Digital Man   
   JS Object save_msg()   
   21 Dec 24 19:26:48   
   
   TZUTC: 1100   
   MSGID: 50243.dove-syncdisc@12:1/2 2bcc760b   
   REPLY: 53290.sync@1:103/705 2bcbdbc9   
   PID: Synchronet 3.20a-Linux master/7b932f63e Dec  9 2023 GCC 10.2.1   
   TID: SBBSecho 3.23-Linux master/445394f9f Dec 20 2024 GCC 12.2.0   
   COLS: 80   
   BBSID: ALTERANT   
   CHRS: CP437 2   
   NOTE: FSEditor.js v1.105   
     Re: JS Object save_msg()   
     By: Digital Man to deon on Fri Dec 20 2024 12:37 pm   
      
   Howdy,   
      
    > Looking/thinking more about the use of time_t for storage of date/time for   
    > posted messages because your questions (thank you for those), I do see a   
    > flaw, after all these years: If the system (OS) time zone is changed (beyond   
    > just annual daylight versus standard time changes), then the stored   
    > "when_written_time" values in message headers no longer actually reflect the   
    > "wallclock time" of the posted message, as was the intent.   
    >   
    > For example, I post/save a message right now and it reflects (correctly):   
    > Dec-20-2024 12:30 PM, PST and it stores the current time_t value that   
    > represents that (as can be seen with ctime, etc.).   
      
    > However, if I move to BBS to the U.S. east coast and change the system (OS)   
    > time zone setting that message is now reported as having been posted at:   
    > Dec-20-2024 03:30 PM, PST   
      
   Actually, I was pleased to see that messages are stored in time_t, and in fact   
   the "wall time" you mention is still valid? I think its the right approach,   
   because it doesnt represent that actual time a message was written (on your   
   system anyway).   
      
   IE: You posting a message at 12:30pm PST, isnt that 3:30pm on the east coast?   
   Its that PST (aka scfg -> system -> local time zone) setting that is messing   
   things. (I think - because that text is appended to the ctime() results.)   
      
   If that was removed, (or rather changed to control how time is *displayed*   
   only), and then reading messages can still be displayed in PST (if that is   
   what you wanted), or shown "local" time zone (EST? dont know what east cost   
   timezone is called).   
      
   (Additionally, it should be easier to allow users to show times in "their"   
   local time - if it wasnt PST/EST, or for that matter AEDT/+11:00 then you use   
   the users preferred timezone, instead of the system one when rendering a date.)   
      
   IE: Messages, as written as stored in utc (time_t), no change there.   
   When displaying a message, you set the timezone accordingly, then use ctime()?   
   (Dont know the c/c++ function to display time in a differnet timezone, but I   
   know it is manipulated by TZ environment variable right?   
      
   Showing age (which I do like in Sync), its easy to figure out how many hours   
   ago something was posted, by using time_t (utc ints).   
      
    > If someone posted at 4AM in their local   
    > time, that's usually what I want to see in the message header.   
      
   That I agree. Hence why I actually like the time offset appended to the time   
   (+11:00 in my case). When I see a message as ... 04:00:00 +06:00, and its 6pm   
   for me, I know immediately that it was written at 9am my time, and thus 9 hrs   
   ago. But I do agree the timezone string looks good too, just harder to the   
   math.   
      
      
   ...лоеп   
      
   ---   
    ю Synchronet ю AnsiTEX bringing back videotex but with ANSI   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 103/705 105/81 106/201 124/5016 128/187 153/757 7715 154/10   
   SEEN-BY: 154/30 203/0 218/700 221/0 226/30 227/114 229/110 114 206   
   SEEN-BY: 229/317 400 426 428 470 550 700 705 240/1120 5832 266/512   
   SEEN-BY: 280/464 5003 5006 282/1038 291/111 292/8125 301/1 310/31   
   SEEN-BY: 320/219 322/757 341/66 234 342/200 396/45 423/120 460/58   
   SEEN-BY: 460/256 1124 467/888 633/280 712/848 770/1 902/26 5020/400   
   SEEN-BY: 5054/30 5075/35   
   PATH: 103/705 280/464 460/58 229/426   
      

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca