TZUTC: -0800   
   MSGID: 53261.sync@1:103/705 2bc90df6   
   REPLY: 50208.dove-syncdisc@12:1/2 2bc8cf19   
   PID: Synchronet 3.20a-Linux master/bbf9d5eac Dec 14 2024 GCC 12.2.0   
   TID: SBBSecho 3.23-Linux master/bbf9d5eac Dec 14 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 12:58 am   
      
    >  >  > Why have a configured timezone at all?   
    >   
    >  > Explained above.   
    >   
    > OK, fair enough. I guess I dont understand why a sysop would configure their   
    > OS timezone different to their BBS timezone.   
      
   They shouldn't normally: hence the warning upon startup. But some sysops may   
   legitimately want to display local times in UTC (big with HAM operators) and   
   maybe have some good reason why their system/OS is not configured for UTC as   
   well.   
      
    > If they didnt have access to the OS configuration, then fair enough, but I   
    > would have thought that was a pretty rare/remote case - and in that case   
    > setting that scfg...Local Time Zone setting could be used to display the   
    > times in that timezone they wanted.   
      
   You're suggesting that SCFG display the current date/time (and zone string) in   
   each timezone that's choosable? That'd be doable, if that's what you're   
   suggesting.   
      
    >  > Your message came here as posted on:   
    >  > "Wed Dec 18 2024 05:14 pm AEDT (30 minutes ago)"   
    >   
    >  > If we only used "what the OS returns", your message would have been   
    >  > posted on: "Wed Dec 18 2024 05:14 pm +11:00 (30 minutes ago)"   
    >   
    > Personally, I prefer the later. Its pretty absolute, where some folks may   
    > not know what AEDT/ACST/ACDT are.   
      
   You have that option in SCFG as well, by setting the Time Zone to "Other..."   
   but then you won't get automatic daytime saving time adjustment (if you need   
   that).   
      
    > Anyway, while the OS might just give you the timezone UTC offset, a quick   
    > parse of /etc/localtime (on linux and mac at least) would give you the   
    > timezone string as well. Dont know if that is at all possible on Win.   
      
   Nothing's impossible. We could do more to work around a sysop that doesn't use   
   the config wizard and ignores warnings.  But I don't see how that'd   
   help your situation now.   
      
    > Personally I think that's better than a scenario where the time or time_t   
    > value is forced to a timezone that makes the usage of that value untrue.   
    >    
      
   time_t values are always in UTC (they're not impacted by any timezone   
   setting). The *dispaly* of the time_t value (in numeric or verbal form) can   
   adjust for the local timezone of the reader or the local timezone of the   
   originator or do no adjustment. When Synchronet displays date/time stamps of   
   messages, it displays it in the local time of the originator (which can be   
   UTC), but the underlying time_t value is always in UTC.   
   --    
                                               digital man (rob)   
      
   Synchronet/BBS Terminology Definition #93:   
   UTF-8 = 8-bit Unicode Transformation Format   
   Norco, CA WX: 73.0øF, 21.0% humidity, 2 mph S 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 550 700 705 240/1120 5832 266/512 280/464   
   SEEN-BY: 280/5003 5006 282/1038 291/111 292/8125 301/1 310/31 320/219   
   SEEN-BY: 322/757 341/66 234 342/200 396/45 423/120 460/58 256 1124   
   SEEN-BY: 467/888 633/280 712/848 770/1 902/26 5020/400 5054/30 5075/35   
   PATH: 103/705 280/464 460/58 229/426