1.8.2018e

Delphi TZDB 2018e Update

Summary

This update is mainly to restore compatibility with older versions of Delphi and bring the TZDB up to date with the current release from the IANA.

I've also updated the list of Windows timezone alias's recognised by the library, the source data for this was the CLDR (v33.1) mapping list.

Bug Fixes

• Fixed an access violation in TBundledTimeZone.Destroy, code not checking if FPeriods was NIL before freeing it or the items it owned. This could happen when the TZID passed in the constructor was invalid.

Enhancements

• Added SupportsGenerics IFDEF to restore compatibility with Delphi versions 6 - 2007.

Updates

• Updated to TZDB 2018e (Release Notes below)
• Updated to CLDR 33.1 for Windows TZ alias's

[tz-announce] 2018e release of tz code and data available

The 2018e release of the tz code and data is available. It reflects the
following changes, which were either circulated on the tz mailing list
or are relatively minor technical or administrative changes:

Briefly

North Korea switches back to +09 on 2018-05-05.
The main format uses negative DST again, for Ireland etc.
'make tarballs' now also builds a rearguard tarball.
New 's' and 'd' suffixes in SAVE columns of Rule and Zone lines.

Changes to past and future time stamps

North Korea switches back from +0830 to +09 on 2018-05-05.
(Thanks to Kang Seonghoon, Arthur David Olson, Seo Sanghyeon,
and Tim Parenti.)

Bring back the negative-DST changes of 2018a, except be more
compatible with data parsers that do not support negative DST.
Also, this now affects historical time stamps in Namibia and the
former Czechoslovakia, not just Ireland.  The main format now uses
negative DST to model time stamps in Europe/Dublin (from 1971 on),
Europe/Prague (1946/7), and Africa/Windhoek (1994/2017).  This
does not affect UT offsets, only time zone abbreviations and the
tm_isdst flag.  Also, this does not affect rearguard or vanguard
formats; effectively the main format now uses vanguard instead of
rearguard format.  Data parsers that do not support negative DST
can still use data from the rearguard tarball described below.

Changes to build procedure

The command 'make tarballs' now also builds the tarball
tzdataVERSION-rearguard.tar.gz, which is like tzdataVERSION.tar.gz
except that it uses rearguard format intended for trailing-edge
data parsers.

Changes to data format and to code

The SAVE column of Rule and Zone lines can now have an 's' or 'd'
suffix, which specifies whether the adjusted time is standard time
or daylight saving time.  If no suffix is given, daylight saving
time is used if and only if the SAVE column is nonzero; this is
the longstanding behavior.  Although this new feature is not used
in tzdata, it could be used to specify the legal time in Namibia
1994-2017, as opposed to the popular time (see below).

Changes to past time stamps

From 1994 through 2017 Namibia observed DST in winter, not summer.
That is, it used negative DST, as Ireland still does.  This change
does not affect UTC offsets; it affects only the tm_isdst flag and
the abbreviation used during summer, which is now CAT, not WAST.
Although (as noted by Michael Deckers) summer and winter time were
both simply called "standard time" in Namibian law, in common
practice winter time was considered to be DST (as noted by Stephen
Colebourne).  The full effect of this change is only in vanguard
format; in rearguard and main format, the tm_isdst flag is still
zero in winter and nonzero in summer.

In 1946/7 Czechoslovakia also observed negative DST in winter.
The full effect of this change is only in vanguard format; in
rearguard and main formats, it is modeled as plain GMT without
daylight saving.  Also, the dates of some 1944/5 DST transitions
in Czechoslovakia have been changed.

1.82.2018c

Added New Functions to the TBundledTimeZone class

• OperatesDayligtTime - Return True if the timezone is operating Daylight time for the specified year
• DaylightTimeStart - Returns the start time of daylight time in timezone local time for the specified year
• DaylightTimeEnd - Returns the end time of daylight time in timezone local time for the specified year
• StardardTimeStart - Returns the start time of standard time in timezone local time for the specified year
• StandardTimeEnd - Returns the end time of standard time in timezone local time for the specified year
• InvalidTimeStart - Returns the start time of Invalid time in timezone local time for the specified year
• InvalidTimeEnd - Returns the end time of Invalid time in timezone local time for the specified year
• AmbiguousTimeStart - Returns the Start time of Ambiguous in timezone local time for the specified year
• AmbiguousTimeEnd - Returns the end time of Ambiguous in timezone local time for the specified year
• ToISO8601Str - Returns the ISO8601 date time string that corresponds to the passed UTC time.

fixed Issues
#1 Test_Africa_Cairo_2010: ETestFailure
#2 Test_Africa_Cairo_2009: ETestFailure
#3 Test_Africa_Accra_1997: ETestFailure
#4 Test_America_Araguaina_1950: ETestFailure
#5 Test_Etc_GTM12_2010: ETestFailure
#6 Test_Etc_GTMMin9_1991: ETestFailure
#9 Bug with DST for America/St_Johns and possibly others 9028f34

Other

Fixed a bug where GetDisplayName was returning the both the std and dst name separated with a slash if it was '/' separated in the zone FOTMAT column in the TZDB files.

Commit bc288b7

FROM IANA TZDB:

The FORMAT column specifies the usual abbreviation of the time zone name. It can have one of three forms:

• a string of three or more characters that are either ASCII alphanumerics, “+”, or “-”, in which case that’s the abbreviation
• a pair of strings separated by a slash (‘/’), in which case the first string is the abbreviation for the standard time name and the second string is the abbreviation for the daylight saving time name
• a string containing “%s,” in which case the “%s” will be replaced by the text in the appropriate Rule’s LETTER col