TZUTC: -0800   
   MSGID: 53307.sync@1:103/705 2bcd4cc2   
   REPLY: 50251.dove-syncdisc@12:1/2 2bcd3c9d   
   PID: Synchronet 3.20a-Linux master/f9ad15e85 Dec 21 2024 GCC 12.2.0   
   TID: SBBSecho 3.23-Linux master/f9ad15e85 Dec 21 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 Sun Dec 22 2024 09:33 am   
      
    >   Re: JS Object save_msg()   
    >   By: Digital Man to deon on Sun Dec 22 2024 10:14 am   
    >   
    > Howdy,   
    >   
    >  >  > 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.)   
    >   
    >  > That's how messages are sent over message networks though, the date/time   
    >  > stamp in the message header is the *local* time at site of the posting.   
    >   
    > I'm not following your point.   
    >   
    > I'll use an example, and for now pretend we didnt have scfg -> System ->   
    > Local Time Zone - we just used ctime(), and our OS's are set to our current   
    > time zone.   
    >   
    > If you wrote your message at 22 Dec 2024 13:30 PST (or UTC-8:00), which is   
    > time_t 1734759000 (on your system). It would display on you system as that,   
    > and if you exported the mail over the network, it would be exported as 22   
    > Dec 2024 13:30 (string) with a TZUTC string of -0800.   
    >   
    > When that message arrived on my system (UTC+11:00), it would be presented to   
    > me as the same time (UTC-08:00), and converted to the same time_t   
    > 1734759000.   
      
   No, it would not. The mktime() standard C library function uses *your* local   
   time zone (not mine) in the conversion to time_t. There isn't a standard C   
   runtime library function that takes a broken-down date/time and converts it to   
   a time_t using an arbitrary (user supplied) time zone. The rest of your message   
   seemed dependant on this first incorrect assumption.   
   --    
                                               digital man (rob)   
      
   Steven Wright quote #17:   
   Ambition is a poor excuse for not having enough sense to be lazy.   
   Norco, CA WX: 68.8øF, 36.0% humidity, 7 mph W 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