[pmmail-list] fetchtime ? - Probable explanation

PMMail OS/2 Support pmmail-list@blueprintsoftwareworks.com
Wed, 04 Apr 2001 15:33:44 -0300


On Tue, 03 Apr 2001 23:49:52 +0200, Michael Gerdau wrote:

>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)
[...]

>I yearly reported it to Southsoft and Blueprintsoftwareworks eversince
>I first came across it.
>
>So far I have not had any reaction [From Blueprint Software Works]

Here is a reply from the developer:

==================BEGIN FORWARDED MESSAGE==================
The bug is caused by the fact that PMMail uses the Windows API
GetTimeZoneInformation *and* in the same code uses the C-library time
functions for misc. time calculations. There's nothing wrong with
using the Windows APIs for this purpose, but when doing this, it is
of utmost importance that the C-library calculation is disabled. You
can't have both in effect, because that will of course give the wrong
result when both your code (using the Win API) and the C-library
tries to compensate for DST. [...]

I have now made sure that the TZ variable always is reset for the
PMMail process. This should take care of the problem permanently.

FWIW, the MSVC++ TZ implementation is crippled and cannot handle the
long format suggested [above]. But, it's still a good suggestion and
it probably works well in PMMail/2 ;-) 
===================END FORWARDED MESSAGE===================


--
Trevor Smith
PMMail/2 Technical Support
pmmailos2@blueprintsoftwareworks.com

- 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