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...

 NB> I have no idea. All I know is that Golded was putting in the
 NB> correct TZUTC. 

or the wrong one if your clock is on UTC as you stated ;)

the time in the message header and the TZUTC have to match together...

  msg time is UTC     = TZUTC 0000
  msg time is EST5EDT = TZUTC 0500
  msg time is CST6CDT = TZUTC 0600

and so on...

 NB> Maybe it accesses my timezone data, which is setup as 
 NB> America/Chicago, since it's the closest to me and matches the
 NB> timezone.

i dunno... if the time in the message is the same time on the system clock
and the system clock is UTC, then i would say something is wrong... it
warrants investigation... especially when mixing software that may use
different methods or not...

aside: one also has to be careful when choosing their timezone because
there are two that appear to be the same... one is POSIX and the other is
not... while they appear to indicate the same timezone, they are actually
12 hours off... how is this possible? because one is added to the clock
time whereas the other is subtracted from the clock time... yeah, that is
confusing but where it matters is in the formula which always adds or
always subtracts no matter what the sign is on the timezone offset...

  eg: EST5EDT == UTC + (-5)

yeah, effectively that is subtracting but the formula's addition is what
matters... you don't subtract is the sign is negative for this setting...
the other one i mention above would be exactly the oposite...

i'm used to the BIOS clock saying the same thing as the system clock which
is the same thing as my wall clock... *nix generally runs the BIOS clock in
UTC and automatically adjusts the system clock based on the timezone
information... if the timezone is set to UTC then the BIOS clock and the
system clock are both the same and TZUTC would be 0000...

[trim]

 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...

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

 :)

figuring out exactly what software does is a good puzzle, too, isn't it? it
can get real interesting like this when the OS has its quirks to consider
as well :)

 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...

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

understood... one of them is incorrect... the task at hand is to figure out
which one and how to correct it ;)

)\/(ark

---