Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com Message-ID: <38033090.DA1F7F7F@btv.ibm.com> Date: Tue, 12 Oct 1999 08:58:56 -0400 From: Randolph Back X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: cygwin AT sourceware DOT cygnus DOT com Subject: Re: date and TZ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The reason date and time is failing at this time has to do with the Win32 GetTimeZoneInformation function and its use in the winsup/times.cc module, the localtime() function. Fortunately, there is a simple work around. GetTimeZoneInformation returns the "date" that standard time starts and daylight savings time starts. The return value can be easily confused because the "dates" may be in one of two formats, one of which is NOT a date. For the beginnning of standard time, my system was returning a "date" of Sunday, 10/5/0000 meaning that daylight time would end on the last sunday of October. The year of 0000 indicates that the "date" is not a date but an encoding of the rules for daylight savings time. The POSIX tzinfo uses a similar format, but does not shove the information into a structure normally used for dates. Unfortunately the Cygwin localtime function interpreted this to mean October 5, whence it went back to standard time on Tuesday, October 5. The workaround is to call SetTimeZoneInformation in a Win32 program and specify the correct date of October 31, 1999. This information will be saved in the registry, so CGYWIN programs will return the correct time (at least until next spring), when hopefully we'll all be running a version with support for TZ. -- Randolph Back 802-871-3508 -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com