[pmmail-list] fetchtime ? - Probable explanation

[Michael Gerdau]

Hi !

I'm answering a couple of mails in this one.

Simon Wright wrote:

>About the TZ issue, does the problem still occur if you use the
>full TZ variable?
>
>in my case:
>
>SET TZ=CET-1CDT,3,-1,0,3600,10,-1,0,3600,3600
>
>for Switzerland or only if you use the short form of SET
>TZ=CET-1CDT (or whatever)? As far as I know, the short form will
>default to the US-standard of DST changes. To implement European
>standard I believe that you need to say exactly when the time
>change will occur.

It happens with the full setting as well.

I have tried both
TZ=CET-1CED,3,-1,0,7200,10,-1,0,10800,3600 (IBM VAC style)
and
TZ=CET-1CED,M3.5.0/2:00,M10.5.0/3:00 (POSIX; EMX OS/2; gcc AFAIK)

Both of the above strings do mean switch on last week of march during
night Sa/So at 02:00 by 1 hour and go back on last week of october
during night Sa/So at 03:00.

Omitting the last part means "default to whatever the c-runtime lib
feels should be the default" (note: with most compilers coming from
the US this usually is US handling - however there is nothing in the
standard saying it has to be US).

Unfortunately the MS VC c-runtime lib does only support the first
three fields. I therefor assume this is the *real* reason for this
IMO rather weird behavior.

The problem only exists for 1 week a year, i.e. when central europe
already has switched to DST while the US has not yet. 7 days later
there is no more problem.


Ulrich Jakobus wrote:

>I was also a couple of years ago frustated by the incorrect
>treatment of TZ settings in Windows using PMMail, Infozip's
>zip and unzip, and also RCS, the revision control system.
>My experience in this regard:
>
> a) Setting TZ=CET-1CED-2,M3.5.0,M10.5.0 for Central Europe
>      PMMail is correct
>      RCS puts in correct timestamps
>      zip/unzip have a 1 hour offset when DST becomes active
>      (this is only relevant if one zips e.g. on Win32 and
>      unzips on another system or in another timezone)
>
> b) Not setting TZ at all
>      PMMail is correct
>      zip/unzip are correct
>      RCS is wrong (this can however be corrected by applying
>      a patch to the source and setting RCSTZ=CET-1CED-2,M3.5.0,M10.5.0)

As I already wrote:
using POSIX does not help during the 1 week central europe is in front
of the US (which leads me to believe they simply ignore anything
after the thrid field).

I'm not sure it is an issue anywhere else in the world though.
In central europe we switched during the night from 24./25. March.
From then on PMMail was one our off unless I completely remove TZ.

Apparently the US switched during 31.March/1.April. Since then I
can again set my TZ and PMMail remains correct.

This happened during the last couple of years. The problem exists
for 7 days and vanishes.



I yearly reported it to Southsoft and Blueprintsoftwareworks eversince
I first came across it.

So far I have not had any reaction apart from a small exchange with
Bob when he asked me about some specifics w/r to determining which
would be the acronym of particular timezones.

In my reports I always remarked that the problem might be specific
to europe and not detectable in the US (usually together with offering
assistance in tracking it down).

So far no reaction whatsoever.

Therefor I'm kind of frustrated.

Best,
Michael
--
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mgd@technosis.de
 Windows NT = Windows, Nice Try!
 PGP-keys available on request or at public keyserver

- pmmail-list - The PMMail Dicussion List ---------------------------
To UNSUBSCRIBE, send a message to mdaemon@bmtmicro.com with the first 
line of the message body being...
UNSUBSCRIBE pmmail-list@blueprintsoftwareworks.com