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,864 of 43,341   
   Digital Man to deon   
   JS Object save_msg()   
   19 Dec 24 11:43:46   
   
   TZUTC: -0800   
   MSGID: 53271.sync@1:103/705 2bca7d89   
   REPLY: 50218.dove-syncdisc@12:1/2 2bc9e554   
   PID: Synchronet 3.20a-Win32 master/39b964536 Dec 16 2024 MSC 1916   
   TID: SBBSecho 3.23-Linux master/c33ca5aac Dec 18 2024 GCC 12.2.0   
   COLS: 80   
   BBSID: VERT   
   CHRS: CP437 2   
   NOTE: FSEditor.js v1.105   
     Re: JS Object save_msg()   
     By: deon to Digital Man on Thu Dec 19 2024 08:45 pm   
      
    > Following on from my previous message, I think I understand what is going on   
    > - doesnt make sense to me why, but I get it.   
    >   
    > I raised this thread, because a message I just saved with save_msg(), when   
    > immediately read would display a message of "11hrs from now".   
    >   
    > I looked further into the code, and understand what age_of_posted_item()   
    > with smb_tzutc() is doing.   
    >   
    > When Sync starts, xpTimeZone_local() shows the offset from UTC, and sends a   
    > warning message on the console on startup, in my case its 660.   
      
   Right, and that startup warning was to hopefully avoid configuration issues   
   like you observed ("11hrs from now").   
      
    > When saving a message with save_msg(), when_written_time, is populated with   
    > time() if no value is provided, which is the UTC time when the function is   
    > called.   
    >   
    > When displaying the message, the age is calculated between the value of   
    > when_written_time (which is utc), and time() [utc] minus xpTimeZone_local()   
    > plus an offset (which might be negative) derived from scfg -> System ->   
    > Local Time Zone.   
      
   The "Local Time Zone" is only used for locally posted messages. For messages   
   imported from a network, the when_written_zone is often not the same as your   
   local time zone.   
      
    > Since I had UTC there, it would be zero, so the age of the   
    > messages is immediately 660s old (utc minus 660 plus 0).   
    >   
    > Thus when when scfg -> System ->Local Time Zone equals xpTimeZone_Local(),   
    > they cancel each other out and age_of_posted_item() is truely however many   
    > seconds ago the message was stored. (utc minus 660 plus 660).   
    >   
    > If this is what is intended, then OK, I get it. Why somebody would find this   
    > useful I guess I dont understand.   
      
   Synchronet's been evolving since 1990, so not every feature or design decision   
   is obvious. I don't know that it would be useful for a sysop to have a   
   mismatch between the UTC offset of their configured local time zone (in SCFG)   
   and their system time zone. Clearly, such a system could present surprising   
   results in some situations; you pointed one out, but there are probably more.   
   That startup warning message should probably be elevated to an error message.   
   --    
                                               digital man (rob)   
      
   Rush quote #9:   
   One likes to believe in the freedom of ... baseball!   
   Norco, CA WX: 81.5øF, 14.0% humidity, 1 mph NE wind, 0.00 inches rain/24hrs   
   --- SBBSecho 3.23-Linux   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 10/0 1 102/401 103/1 17 705 105/81 106/201 124/5016 128/187   
   SEEN-BY: 153/7715 218/0 1 215 601 700 840 860 880 226/30 227/114 229/110   
   SEEN-BY: 229/114 206 317 400 426 428 470 550 700 705 266/512 280/464   
   SEEN-BY: 282/1038 291/111 301/1 320/219 322/757 342/200 396/45 460/58   
   SEEN-BY: 633/280 712/848 902/26 5075/35   
   PATH: 103/705 218/700 229/426   
      

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


(c) 1994,  bbs@darkrealms.ca