🚀 go-pugleaf

I've recently ported Snews (the J.W. version) across to DJGPP, and it's
highlighted an anomaly with the timezone setting.

Allowing for the fact that the documentation is out of date (unless
there are more recent versions available) with regard to when
summertime/daylight saving should be applied, I believe the currently
"recommended" value for KA9Q/Snews is :-

        set [G]TZ=GMT0BST1,M3.5.0/01:00,M10.5.0/02:00

When I noticed my Date: header was being tagged as "-0100 (BST)" my
first suspicion was that *I'd* got the sign wrong (which I fixed), but
then I also noticed the date part of the msg-id, formed via a call to
gmtime() was an hour *ahead* of the current PC clock (set in BST)...

I did some experiments and discovered that both the "raw" Borland time
functions, and the GeK replacement module (tzset.c) don't seem to care
about the 2nd offset above - regardless of the sign and/or value used
(or indeed even if it's missing, i.e. "GMT0BST,M3..."), summertime is
hardcoded (correctly in this case) as an hour ahead, or if you prefer
GMT is calculated as an hour *behind* current local/summer time.

(Though it's also worth mentioning that the GeK module *needs* that
extra info after the comma, otherwise it defaults to GMT all year
round... with earlier versions actually assuming EST5).

The native DJGPP functions OTOH make use of the value, and *do* take
note of it's sign. GMT0BST1 get's it wrong as above. In order to get the
correct behaviour, with BST/local == (GMT + 1hr) either of the following
settings work just fine, *and* just as importantly also work for the
Borland/GeK functions :-

        [G]TZ=GMT0BST,M3.5.0/01:00,M10.5.0/02:00
    and [G]TZ=GMT0BST-1,M3.5.0/01:00,M10.5.0/02:00

(I should have known this having configured WinDIS, which doesn't
support the extended syntax and gets the switch over date wrong, to run
on a setting of just "BST-1" during the summer months).

Right - now the real problem.

As there must be several.... <waves hands expansively> dozen existing
Snews users out there(?), it's probably unwise to release this version
in the expectation that they'll all reliably change their present TZ/GTZ
settings.

I've already got a DJGPP specific fn. for backward compatibility with
the Borland versions, gtzset(). At the moment this simply looks for the
GTZ env.var., and if found uses it to set/override the TZ variable. I'm
thinking of extending this to strip out the 2nd offset, i.e. looking for
any numeric present between the 2nd zone name (BST) and the comma, and
removing it before calling the real (native to DJGPP) tzset() fn.

Can anyone see any flaws with this, or suggest anything better?

--
    ()---()
     (0 0)    Dave Scott   e-mail: dave@roborat.demon.co.uk
----m-( )-m-------------------------------------------------------------
      =o=