Hello mark,

On 03 Dec 12 at 04:17, you wrote to me:

 ml>> how does golded know about the right one? the software i'm
 ml>> familiar with uses the TZUTC environment variable... set it to
 ml>> the proper entry for the local clock and then run your
 ml>> program(s)...

 NB>> It must read my system clock, which uses UTC,

 ml> but the system clock doesn't know if it is running on UTC or local
 ml> time and it has no way of telling the software, either... it is just a
 ml> clock like that beside your bed or hanging on the wall...

I have no idea. All I know is that Golded was putting in the correct TZUTC.
Maybe it accesses my timezone data, which is setup as America/Chicago,
since it's the closest to me and matches the timezone.

 NB>> whereas (I got the answer from Rob) Synchronet has a setting for
 NB>> Local Time. If you select any USA timezone, ie: CDT or CST --
 NB>> which I am in, It seems to give the TZUTC 0000 kludge. This post
 NB>> should be fixed, as I changed Synchronet to UTC -0600. Maybe I
 NB>> found a bug, I don't know. He hasn't responded to me a second
 NB>> time yet.

 ml> this one also carries TZUTC 0000... but you're on *nix, right? unless
 ml> i'm mistaken, most *nix run the clock at UTC and adjust the displayed
 ml> (and logged in some cases) time to the local time by that offset
 ml> setting... i'll have to look again at your header again and see what
 ml> time is in the message to see if it makes sense with the TZUTC
 ml> offset...

That's very possible. Actually, I hope that's the case, because the only
two options I had with Synchronet were tried, with the same result. :)

 ml> you can see how the lack of TZUTC can cause some craziness... an
 ml> incorrect TZUTC will definitely cause some craziness... consider if i
 ml> were in PST8PDT... my software would be seeing no TZUTC as -0800
 ml> instead of -0500 and the time jumping would be even greater and more
 ml> noticible...

If the option would have been there, I would have turned it off in SBBS,
and let Golded take care of it (since it was correct). Unfortunately, that
isn't the case. :(

Regards,
Nick

--- SBBSecho 2.20-Linux