[pmmail-list] fetchtime ? - Probable explanation

[Michael Gerdau]

Hi folks !

All this fetchtime stuff is there in PMMail for quite a few years
now. I have reported this at least three times (if not more often)
without any (apparent) changes whatsoever.

Meanwhile I have done some research as to the cause. FYC I'll insert
my most recent bugreport.

Maybe we could finally lobby the developers into fixing it.

Here my recent bugreport:

--- snip --- snip --- snip --- snip --- snip --- snip --- snip ---
Dear PMMail support !

Here is my yearly complaint about PMMail not correctly handling
DaylightSavingTime !!!

This error is there for a couple of years now and has been reported
by me for quite a few times. I even had a discussion regarding this
topic and correctly handling Timezones with Bob back when PMMail was
OS/2 only.

As it is we do have DST in germany (and most part of europe) since
last weekend - we do switch on last weekend of March and back on
last weekend of october for a couple of years now.

I don't know how PMMail does decide on the correct time - it certainly
does not use Windows (either 2000 or NT) time as that *is* correct while
PMMail is 1 hour off.


I have done some testing on this issue and here is what I found out:
- PMMail does work correctly if and only if there is no setting provided
  for TZ.
- PMMail is 1 hour off when there is provided a TZ. I have further
  investigated this and found the following:
  - Cygnus tools and everything compiled with gcc does correctly
    conform to POSIX w/r to handling TZ.
  - IBM VAC does correctly handle it's own format. The first 3 fields
    are the same as POSIX.
  - Apparently MS VC++ does only know about the first 3 fields of a
    POSIX conformant setting for TZ (i.e. normal name, offset, saving name)
    and happily ignores anything behind it.


While I understand blueprintsoftwareworks is in no position to fix the
shortcomings of MS VC++ standard library, I nevertheless think the
behaviour as it is now is less than satisfactory.

What PMMail apparently does is using TZ when it is set. Due to
shortcomings in MS VC++ standard library this implies that switching
happens conforming to the method employed in the US (which seems to
differ from most of europe).

Simply removing TZ does solve the problem for PMMail. Unfortunately
this is not an acceptable "solution" as this will cause other software
- namely infozips ZIP - to not handle DST correctly.

I therefor kindly ask you to fix this behaviour.

Somewhat annoyed, best,
Michael
--- snip --- snip --- snip --- snip --- snip --- snip --- snip ---

Best,
Michael
--
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mgd@technosis.de
 The Windows Energizer Bunny: It's STILL loading! And loading...
 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