TZUTC: -0800   
   MSGID: 53290.sync@1:103/705 2bcbdbc9   
   REPLY: 53275.sync@1:103/705 2bcab59c   
   PID: Synchronet 3.20a-Linux master/bbf9d5eac Dec 14 2024 GCC 12.2.0   
   TID: SBBSecho 3.23-Linux master/d0e0e8c90 Dec 19 2024 GCC 12.2.0   
   COLS: 80   
   BBSID: VERT   
   CHRS: CP437 2   
   NOTE: FSEditor.js v1.105   
     Re: JS Object save_msg()   
     By: Digital Man to deon on Thu Dec 19 2024 03:42 pm   
      
    >   Re: JS Object save_msg()   
    >   By: deon to Digital Man on Thu Dec 19 2024 08:45 pm   
    >   
    >  > 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.   
    >   
    > The time zone offsets are applied to calculate the age of posted messages to   
    > account for messages received via message networks: the when_written_time   
    > value is a time_t, in UTC, but represents the parsed date/time from the   
    > originating message header (which is the local time for the time zone of the   
    > poster): it's not necessarily the current UTC time at the time of posting   
    > when posted from a different time zone.   
    >   
    > So yes, the adjustments to calculate the message age look unnecessary when   
    > considering only locally posted messages but make sense when considering   
    > network-posted messages.   
      
   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 "   
   hen_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 04:30 PM, PST   
   And that's no longer correct. Hrmph.   
      
   What we really want to store (and display) is just the current wallclock time   
   at the site of posting. time_t isn't really the right datatype to use for this   
   use case. Some encoding of the ISO-8601 representation of the wallclock time   
   would be more appropriate, and then it wouldn't change when the system/OS time   
   zone is changed. The date/time could be displayed in its UTC or local time   
   zone equivalent (if that was desired), but that's not what most BBS users and   
   sysops want. If someone posted at 4AM in their local time, that's usually what   
   I want to see in the message header.   
   --    
                                               digital man (rob)   
      
   Steven Wright quote #28:   
   The hardness of the butter is proportional to the softness of the bread.   
   Norco, CA WX: 72.9øF, 22.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs   
   --- SBBSecho 3.23-Linux   
    * 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