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,851 of 43,341    |
|    Digital Man to deon    |
|    JS Object save_msg()    |
|    17 Dec 24 21:19:44    |
   
   TZUTC: -0800   
   MSGID: 53256.sync@1:103/705 2bc86178   
   REPLY: 50204.dove-syncdisc@12:1/2 2bc84cc0   
   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 Wed Dec 18 2024 03:42 pm   
      
    > Re: JS Object save_msg()   
    > By: Digital Man to deon on Tue Dec 17 2024 05:36 pm   
    >   
    > Howdy,   
    >   
    > > What do you have set in SCFG->System->Local Time Zone? This is the   
    > > default time zone information used by MsgBase.save_msg() and stored in   
    > > the message header (if not otherwise specified in the message header   
    > > object).   
    >   
    > > It should be storing whatever you have configured in SCFG->System->Local   
    > > Time Zone.   
    >   
    > OK, it is UTC in there.   
      
   Is that intentional?   
      
    > So this just is confusing, and IMHO messed up. I must have the wrong   
    > impression of Syncs timezone handling.   
    >   
    > If you dont supply a datetime stamp (via any of the header save attributes   
    > that have a date/time), and Sync "figures it out" why cant it figure out the   
    > timezone of that time it gets as well?   
      
   Synchronet doesn't figure it out, it just uses the timezone you have   
   configured in SCFG->System.   
      
    > Sync obviously knows the time zone - given that it displayed that message,   
    > that it saved 3s earlier with a "UTC" timezone as "11 hrs from now". Its not   
    > using that System->Local->Time Zone when displaying the message?   
      
   It's not. When displaying the timezone of messages, Synchronet uses the   
   timezone of the OS. If the configured timezone (in SCFG->System) and the OS   
   timezone don't agree, the Terminal Server logs a warning during startup:   
   "Configured time zone (x, 0xYYYY, offset: z) does not match system-local time   
   zone offset: n"   
      
   Are you getting this warning log message?   
      
    > I think it can be improved, but if I'm wrong, I'd like to understand why my   
    > thinking is wrong...   
      
   You have a mismatch in your configuration. If that's unintentional, then I   
   guess I could make that warning log message an error instead, to hopefully   
   insure that sysops are aware of it in the future. If it's intentional, then I   
   guess I would want to know why and then figure out how to support such a   
   configuration with fewer surprises.   
      
    > Oh, and there *is* a problem with strftime(), but it may not be SBBS   
    > related.   
    >   
    > 2-3 hrs ago, my test script:   
    >   
    > writeln(strftime("%a, %d %b %Y %I:%M:%S %z",time()));   
    >   
    > was returning a correct date/time and timezone information - had me baffled,   
    > especially after I posted yesterday.   
      
   Are you messing with your system's timezone configuration or TZ environment   
   variable?   
   --    
    digital man (rob)   
      
   Sling Blade quote #12:   
   Karl (re hammer): I don't rightly know. I just kinda woke up holding it.   
   Norco, CA WX: 71.2øF, 18.0% humidity, 0 mph SSE 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   
      
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca