REPLY: 1:282/1031.0 a94878b5   
   MSGID: 1:3634/12.73 5cdf3d71   
   PID: GED+LNX 1.1.5-b20180707   
   CHRS: CP437 2   
   TZUTC: -0400   
   TID: hpt/lnx 1.9.0-cur 07-09-15   
      
    On 2019 May 17 08:47:24, you wrote to Alan Ianson:   
      
    >> BBBS seems to get the time right ok in Pacific Standard Time. It's when   
    >> we spring ahead it doesn't change to Pacific Daylight Time. The   
    >> computers clock does change but the TZUTC: kludge doesn't. I have found   
    >> here that setting the TZ and TZUTC environments is needed, at least in   
    >> PDT. In my case I set TZ=PDT+7 and TZUTC=-0700 and now my TZUTC kludg   
    >> is correct.   
      
    JS> Maybe as a temp workaround in the script file that starts BBBSD you   
    JS> could do a date check. And when the Daylight Saving dates are reached   
    JS> then the TZ and the TZUTC variables could be changed as necessary. For   
    JS> me I would do it via a Bash script.   
      
   it should be easy enough to do ;)   
      
   eg: $ printf "TZUTC=$(date +"%z")\n"   
   TZUTC=-0400   
      
   the real trick will be to execute it at the proper time so that the env var is   
   set when the time changes... the quickest thing i can think of would be for the   
    BBS to exit back to the script and loop through the setting before firing up   
   the BBS again... that should be done at the proper times, though...   
      
   the only problem with the above is that the FTSC spec for TZUTC does not allow   
   for the '+' to be specified for timezones east of UTC... the '+' should be   
   stripped off which makes the above quickie one-liner more involved but not   
   impossible to handle...   
      
   eg: $ printf "TZUTC=$(date +"%z" | sed 's/\+//')\n"   
      
   that'll strip out the '+' if it exists and will leave the '-' alone... so if   
   i've done this playing around correctly, something like   
      
     export TZUTC=$(date +"%z" | sed 's/\+//')   
      
   should work but we have the problem of updating it when daylight saving   
   switches so there still needs to be some sort of updater executed or the BBS   
   would have to exit to the script which would loop, reset the env var and   
   restart the BBS...   
      
   i whipped up this little test script...   
      
   ==== Begin "tzutctest"  ====   
   printf "before setting: '%s'\n" $TZUTC   
   TZUTC=$(date +"%z" | sed 's/\+//')   
   export TZUTC   
   printf "after setting : '%s'\n" $TZUTC   
   env | grep "TZUTC"   
   ==== End "tzutctest" ====   
      
   when the script exits, TZUTC does not exist in the env so that means that a   
   script like this will need to be used for anything that wants the TZUTC env   
   var...   
      
   it would probably be best if the maintainer would check and see if the code   
   does this... the very best would be to check and set the variable when each   
   message is posted when the TZUTC control line is added to the message... this   
   for all messages posted... even for those uploaded via offline mail... QWK/QWKE   
    and BlueWave, which ever are supported...   
      
   one might want to see about putting the above in their ~/.bashrc so that it is   
   set for them when they login to the system... this just in case they use   
   external tools like a sysop reader to access the message base without having to   
    login to the BBS... one might place it in the global /etc/bash.bashrc so that   
   it is run for all accounts instead of just their personal account... instead of   
    using one of the .bashrc files, one might use one of the .profile files or   
   even create a tzutc.sh script and place it in /etc/profile.d...   
      
   if one runs BBBS as a service, it would certainly need to be placed in that   
   script before starting BBBS but then we still have the thing about resetting it   
    when daylight switches over...   
      
   FWIW: this is almost exactly the same dance i had to play on my old OS/2   
   setup... in that case, i had to manually edit the config.sys since that's where   
    these are set and then reboot the system... that only so the native OS/2 side   
   would get updated... the DOS side was easy enough as i just did the loop thing   
   in the BBS .bat/.cmd files... i wrote a tool to determine the timezone since   
   OS/2 doesn't have that in its time records unless you use one of peter moylan's   
    (of weasel SMTP and ftpser server fame) tools...   
      
   oh yeah, the TZ can also be set like this... there's two TZ formats for linux,   
   though...   
      
   TZ='America/New_York'   
   or the POSIX format   
   TZ='EST5EDT'   
      
   which one you use depends on the software needs... some does POSIX and some   
   does not...   
      
   just rambling and trying to stave off depression again...   
      
   )\/(ark   
      
   Always Mount a Scratch Monkey   
   Do you manage your own servers? If you are not running an IDS/IPS yer doin' it   
   wrong...   
   ... I'll have two brains on drugs, scrambled with bacon, grits, toast and   
   coffee.   
   ---   
    * Origin:  (1:3634/12.73)   
   SEEN-BY: 1/123 15/2 57/0 153/250 220/70 226/17 100 229/354 426 452   
   SEEN-BY: 229/1014 240/5832 249/206 317 267/800 280/464 292/854 317/2   
   SEEN-BY: 317/3 322/757 342/200 393/68 770/0 1 10 100 330 340 772/0   
   SEEN-BY: 772/1 500 5020/932   
   PATH: 3634/12 261/38 218/700 103/705 280/464 770/1 393/68 229/426