[Home] [Puzzles & Projects] [Delphi Techniques] [Math topics] [Library] [Utilities]
|
|
I needed time zone adjustment information for a current project, so decided to write a separate program to explore what is available. Since we identify our time zone to Windows at installation time and since it politely asks us to confirm when when it changes the clock for daylight savings time, it seems logical that the information would be available. Sure enough Windows API function GetTimeZoneInformation returns a record, TTimeZoneInformation, with everything you would want to know; Specifically:
The function also returns an integer result indicating:
Delphi provides both the hook to the function and the record definition. Here is a simple program that just calls GetTimeZoneInformation and displays the results. March 8, 2015: A Delphi programmer in Europe recently reported that the start and end dates for Daylight Saving Time (DST) displayed by the program were incorrect. I ran the program here and, sure enough, the results for EST here in the states was also incorrect and probably have been since 2004. It turns out that those DST fields are actually "templates" describing the the Month, DayOfWeek(DOW) and a DayOfMonth field which actually specifies which occurrence of the DOW within the month defines the start and end dates. E.g. "2nd Sunday in March" or "5th (or last) Sunday in October). Version 2 posted today converts that DOW enumeration into an actual Day of Month value and the displays now show proper values, at least for USA and Europe. February 14, 2016: Well, Aussies always like to break the mold and do things differently. They did it again with Daylight Saving Time calculations: Version 2.1 fixes two problem uncovered by a Brisbane programmer when he reported the demo program crashing. It's difficult for me to test here, but I did recall that Windows DST information records only report Month of Year (MOY), Day of Week and Day of Month fields. When ending MOY is less than starting MOY, it's up the programmer to increment to the correct ending year value. When that change didn't fix the user's crash problem, further checking uncovered that some Australian states including Queensland does not have any DST at all and Window record contains all zeros. The program should now report correct end dates for Southern Hemisphere regions and "no DST for this location" instead of crashing when there is none. Changes have not been tested, but someone down under will surely let me know if problems still exist.
|
[Feedback] [Newsletters (subscribe/view)] [About me]Copyright © 2000-2018, Gary Darby All rights reserved. |