bionic/libc/tzcode/tzfile.h

170 lines
5.0 KiB
C
Raw Normal View History

#ifndef TZFILE_H
#define TZFILE_H
/*
** This file is in the public domain, so clarified as of
** 1996-06-05 by Arthur David Olson.
*/
/*
** This header is for use ONLY with the time conversion code.
** There is no guarantee that it will remain unchanged,
** or that it will remain at all.
** Do NOT copy it to any system include directory.
** Thank you!
*/
/*
** Information about time zone files.
*/
#ifndef TZDIR
#define TZDIR "/usr/local/etc/zoneinfo" /* Time zone object file directory */
#endif /* !defined TZDIR */
#ifndef TZDEFAULT
#define TZDEFAULT "localtime"
#endif /* !defined TZDEFAULT */
#ifndef TZDEFRULES
#define TZDEFRULES "posixrules"
#endif /* !defined TZDEFRULES */
/*
** Each file begins with. . .
*/
#define TZ_MAGIC "TZif"
struct tzhead {
char tzh_magic[4]; /* TZ_MAGIC */
Upgrade to tzcode2013f plus Android modifications (from tzcode2013d plus Android modifications). localtime.c and strftime.c are still quite different from upstream because of our extensions, but the other files continue to be identical, and the two exceptions should be otherwise identical. From the tzcode2013e release notes: Changes affecting Godthab time stamps after 2037 if version mismatch Allow POSIX-like TZ strings where the transition time's hour can range from -167 through 167, instead of the POSIX-required 0 through 24. E.g., TZ='FJT-12FJST,M10.3.1/146,M1.3.4/75' for the new Fiji rules. This is a more-compact way to represent far-future time stamps for America/Godthab, America/Santiago, Antarctica/Palmer, Asia/Gaza, Asia/Hebron, Asia/Jerusalem, Pacific/Easter, and Pacific/Fiji. Other zones are unaffected by this change. (Derived from a suggestion by Arthur David Olson.) Allow POSIX-like TZ strings where daylight saving time is in effect all year. E.g., TZ='WART4WARST,J1/0,J365/25' for Western Argentina Summer Time all year. This supports a more-compact way to represent the 2013d data for America/Argentina/San_Luis. Because of the change for San Luis noted above this change does not affect the current data. (Thanks to Andrew Main (Zefram) for suggestions that improved this change.) Where these two TZ changes take effect, there is a minor extension to the tz file format in that it allows new values for the embedded TZ-format string, and the tz file format version number has therefore been increased from 2 to 3 as a precaution. Version-2-based client code should continue to work as before for all time stamps before 2038. Existing version-2-based client code (tzcode, GNU/Linux, Solaris) has been tested on version-3-format files, and typically works in practice even for time stamps after 2037; the only known exception is America/Godthab. Changes affecting API Support for floating-point time_t has been removed. It was always dicey, and POSIX no longer requires it. (Thanks to Eric Blake for suggesting to the POSIX committee to remove it, and thanks to Alan Barrett, Clive D.W. Feather, Andy Heninger, Arthur David Olson, and Alois Treindl, for reporting bugs and elucidating some of the corners of the old floating-point implementation.) The signatures of 'offtime', 'timeoff', and 'gtime' have been changed back to the old practice of using 'long' to represent UT offsets. This had been inadvertently and mistakenly changed to 'int_fast32_t'. (Thanks to Christos Zoulos.) The code avoids undefined behavior on integer overflow in some more places, including gmtime, localtime, mktime and zdump. Changes affecting code internals Minor changes pacify GCC 4.7.3 and GCC 4.8.1. Changes affecting documentation and commentary Documentation and commentary is more careful to distinguish UT in general from UTC in particular. (Thanks to Steve Allen.) From the tzcode2013f release notes: Changes affecting API The types of the global variables 'timezone' and 'altzone' (if present) have been changed back to 'long'. This is required for 'timezone' by POSIX, and for 'altzone' by common practice, e.g., Solaris 11. These variables were originally 'long' in the tz code, but were mistakenly changed to 'time_t' in 1987; nobody reported the incompatibility until now. The difference matters on x32, where 'long' is 32 bits and 'time_t' is 64. (Thanks to Elliott Hughes.) Change-Id: I14937c42a391ddb865e4d89f0783961bcc6baa21
2013-09-27 09:04:30 +02:00
char tzh_version[1]; /* '\0' or '2' or '3' as of 2013 */
char tzh_reserved[15]; /* reserved--must be zero */
char tzh_ttisgmtcnt[4]; /* coded number of trans. time flags */
char tzh_ttisstdcnt[4]; /* coded number of trans. time flags */
char tzh_leapcnt[4]; /* coded number of leap seconds */
char tzh_timecnt[4]; /* coded number of transition times */
char tzh_typecnt[4]; /* coded number of local time types */
char tzh_charcnt[4]; /* coded number of abbr. chars */
};
/*
** . . .followed by. . .
**
** tzh_timecnt (char [4])s coded transition times a la time(2)
** tzh_timecnt (unsigned char)s types of local time starting at above
** tzh_typecnt repetitions of
Upgrade to tzcode2013f plus Android modifications (from tzcode2013d plus Android modifications). localtime.c and strftime.c are still quite different from upstream because of our extensions, but the other files continue to be identical, and the two exceptions should be otherwise identical. From the tzcode2013e release notes: Changes affecting Godthab time stamps after 2037 if version mismatch Allow POSIX-like TZ strings where the transition time's hour can range from -167 through 167, instead of the POSIX-required 0 through 24. E.g., TZ='FJT-12FJST,M10.3.1/146,M1.3.4/75' for the new Fiji rules. This is a more-compact way to represent far-future time stamps for America/Godthab, America/Santiago, Antarctica/Palmer, Asia/Gaza, Asia/Hebron, Asia/Jerusalem, Pacific/Easter, and Pacific/Fiji. Other zones are unaffected by this change. (Derived from a suggestion by Arthur David Olson.) Allow POSIX-like TZ strings where daylight saving time is in effect all year. E.g., TZ='WART4WARST,J1/0,J365/25' for Western Argentina Summer Time all year. This supports a more-compact way to represent the 2013d data for America/Argentina/San_Luis. Because of the change for San Luis noted above this change does not affect the current data. (Thanks to Andrew Main (Zefram) for suggestions that improved this change.) Where these two TZ changes take effect, there is a minor extension to the tz file format in that it allows new values for the embedded TZ-format string, and the tz file format version number has therefore been increased from 2 to 3 as a precaution. Version-2-based client code should continue to work as before for all time stamps before 2038. Existing version-2-based client code (tzcode, GNU/Linux, Solaris) has been tested on version-3-format files, and typically works in practice even for time stamps after 2037; the only known exception is America/Godthab. Changes affecting API Support for floating-point time_t has been removed. It was always dicey, and POSIX no longer requires it. (Thanks to Eric Blake for suggesting to the POSIX committee to remove it, and thanks to Alan Barrett, Clive D.W. Feather, Andy Heninger, Arthur David Olson, and Alois Treindl, for reporting bugs and elucidating some of the corners of the old floating-point implementation.) The signatures of 'offtime', 'timeoff', and 'gtime' have been changed back to the old practice of using 'long' to represent UT offsets. This had been inadvertently and mistakenly changed to 'int_fast32_t'. (Thanks to Christos Zoulos.) The code avoids undefined behavior on integer overflow in some more places, including gmtime, localtime, mktime and zdump. Changes affecting code internals Minor changes pacify GCC 4.7.3 and GCC 4.8.1. Changes affecting documentation and commentary Documentation and commentary is more careful to distinguish UT in general from UTC in particular. (Thanks to Steve Allen.) From the tzcode2013f release notes: Changes affecting API The types of the global variables 'timezone' and 'altzone' (if present) have been changed back to 'long'. This is required for 'timezone' by POSIX, and for 'altzone' by common practice, e.g., Solaris 11. These variables were originally 'long' in the tz code, but were mistakenly changed to 'time_t' in 1987; nobody reported the incompatibility until now. The difference matters on x32, where 'long' is 32 bits and 'time_t' is 64. (Thanks to Elliott Hughes.) Change-Id: I14937c42a391ddb865e4d89f0783961bcc6baa21
2013-09-27 09:04:30 +02:00
** one (char [4]) coded UT offset in seconds
** one (unsigned char) used to set tm_isdst
** one (unsigned char) that's an abbreviation list index
** tzh_charcnt (char)s '\0'-terminated zone abbreviations
** tzh_leapcnt repetitions of
** one (char [4]) coded leap second transition times
** one (char [4]) total correction after above
** tzh_ttisstdcnt (char)s indexed by type; if TRUE, transition
** time is standard time, if FALSE,
** transition time is wall clock time
** if absent, transition times are
** assumed to be wall clock time
** tzh_ttisgmtcnt (char)s indexed by type; if TRUE, transition
Upgrade to tzcode2013f plus Android modifications (from tzcode2013d plus Android modifications). localtime.c and strftime.c are still quite different from upstream because of our extensions, but the other files continue to be identical, and the two exceptions should be otherwise identical. From the tzcode2013e release notes: Changes affecting Godthab time stamps after 2037 if version mismatch Allow POSIX-like TZ strings where the transition time's hour can range from -167 through 167, instead of the POSIX-required 0 through 24. E.g., TZ='FJT-12FJST,M10.3.1/146,M1.3.4/75' for the new Fiji rules. This is a more-compact way to represent far-future time stamps for America/Godthab, America/Santiago, Antarctica/Palmer, Asia/Gaza, Asia/Hebron, Asia/Jerusalem, Pacific/Easter, and Pacific/Fiji. Other zones are unaffected by this change. (Derived from a suggestion by Arthur David Olson.) Allow POSIX-like TZ strings where daylight saving time is in effect all year. E.g., TZ='WART4WARST,J1/0,J365/25' for Western Argentina Summer Time all year. This supports a more-compact way to represent the 2013d data for America/Argentina/San_Luis. Because of the change for San Luis noted above this change does not affect the current data. (Thanks to Andrew Main (Zefram) for suggestions that improved this change.) Where these two TZ changes take effect, there is a minor extension to the tz file format in that it allows new values for the embedded TZ-format string, and the tz file format version number has therefore been increased from 2 to 3 as a precaution. Version-2-based client code should continue to work as before for all time stamps before 2038. Existing version-2-based client code (tzcode, GNU/Linux, Solaris) has been tested on version-3-format files, and typically works in practice even for time stamps after 2037; the only known exception is America/Godthab. Changes affecting API Support for floating-point time_t has been removed. It was always dicey, and POSIX no longer requires it. (Thanks to Eric Blake for suggesting to the POSIX committee to remove it, and thanks to Alan Barrett, Clive D.W. Feather, Andy Heninger, Arthur David Olson, and Alois Treindl, for reporting bugs and elucidating some of the corners of the old floating-point implementation.) The signatures of 'offtime', 'timeoff', and 'gtime' have been changed back to the old practice of using 'long' to represent UT offsets. This had been inadvertently and mistakenly changed to 'int_fast32_t'. (Thanks to Christos Zoulos.) The code avoids undefined behavior on integer overflow in some more places, including gmtime, localtime, mktime and zdump. Changes affecting code internals Minor changes pacify GCC 4.7.3 and GCC 4.8.1. Changes affecting documentation and commentary Documentation and commentary is more careful to distinguish UT in general from UTC in particular. (Thanks to Steve Allen.) From the tzcode2013f release notes: Changes affecting API The types of the global variables 'timezone' and 'altzone' (if present) have been changed back to 'long'. This is required for 'timezone' by POSIX, and for 'altzone' by common practice, e.g., Solaris 11. These variables were originally 'long' in the tz code, but were mistakenly changed to 'time_t' in 1987; nobody reported the incompatibility until now. The difference matters on x32, where 'long' is 32 bits and 'time_t' is 64. (Thanks to Elliott Hughes.) Change-Id: I14937c42a391ddb865e4d89f0783961bcc6baa21
2013-09-27 09:04:30 +02:00
** time is UT, if FALSE,
** transition time is local time
** if absent, transition times are
** assumed to be local time
*/
/*
** If tzh_version is '2' or greater, the above is followed by a second instance
** of tzhead and a second instance of the data in which each coded transition
** time uses 8 rather than 4 chars,
** then a POSIX-TZ-environment-variable-style string for use in handling
** instants after the last transition time stored in the file
** (with nothing between the newlines if there is no POSIX representation for
** such instants).
Upgrade to tzcode2013f plus Android modifications (from tzcode2013d plus Android modifications). localtime.c and strftime.c are still quite different from upstream because of our extensions, but the other files continue to be identical, and the two exceptions should be otherwise identical. From the tzcode2013e release notes: Changes affecting Godthab time stamps after 2037 if version mismatch Allow POSIX-like TZ strings where the transition time's hour can range from -167 through 167, instead of the POSIX-required 0 through 24. E.g., TZ='FJT-12FJST,M10.3.1/146,M1.3.4/75' for the new Fiji rules. This is a more-compact way to represent far-future time stamps for America/Godthab, America/Santiago, Antarctica/Palmer, Asia/Gaza, Asia/Hebron, Asia/Jerusalem, Pacific/Easter, and Pacific/Fiji. Other zones are unaffected by this change. (Derived from a suggestion by Arthur David Olson.) Allow POSIX-like TZ strings where daylight saving time is in effect all year. E.g., TZ='WART4WARST,J1/0,J365/25' for Western Argentina Summer Time all year. This supports a more-compact way to represent the 2013d data for America/Argentina/San_Luis. Because of the change for San Luis noted above this change does not affect the current data. (Thanks to Andrew Main (Zefram) for suggestions that improved this change.) Where these two TZ changes take effect, there is a minor extension to the tz file format in that it allows new values for the embedded TZ-format string, and the tz file format version number has therefore been increased from 2 to 3 as a precaution. Version-2-based client code should continue to work as before for all time stamps before 2038. Existing version-2-based client code (tzcode, GNU/Linux, Solaris) has been tested on version-3-format files, and typically works in practice even for time stamps after 2037; the only known exception is America/Godthab. Changes affecting API Support for floating-point time_t has been removed. It was always dicey, and POSIX no longer requires it. (Thanks to Eric Blake for suggesting to the POSIX committee to remove it, and thanks to Alan Barrett, Clive D.W. Feather, Andy Heninger, Arthur David Olson, and Alois Treindl, for reporting bugs and elucidating some of the corners of the old floating-point implementation.) The signatures of 'offtime', 'timeoff', and 'gtime' have been changed back to the old practice of using 'long' to represent UT offsets. This had been inadvertently and mistakenly changed to 'int_fast32_t'. (Thanks to Christos Zoulos.) The code avoids undefined behavior on integer overflow in some more places, including gmtime, localtime, mktime and zdump. Changes affecting code internals Minor changes pacify GCC 4.7.3 and GCC 4.8.1. Changes affecting documentation and commentary Documentation and commentary is more careful to distinguish UT in general from UTC in particular. (Thanks to Steve Allen.) From the tzcode2013f release notes: Changes affecting API The types of the global variables 'timezone' and 'altzone' (if present) have been changed back to 'long'. This is required for 'timezone' by POSIX, and for 'altzone' by common practice, e.g., Solaris 11. These variables were originally 'long' in the tz code, but were mistakenly changed to 'time_t' in 1987; nobody reported the incompatibility until now. The difference matters on x32, where 'long' is 32 bits and 'time_t' is 64. (Thanks to Elliott Hughes.) Change-Id: I14937c42a391ddb865e4d89f0783961bcc6baa21
2013-09-27 09:04:30 +02:00
**
** If tz_version is '3' or greater, the above is extended as follows.
** First, the POSIX TZ string's hour offset may range from -167
** through 167 as compared to the POSIX-required 0 through 24.
** Second, its DST start time may be January 1 at 00:00 and its stop
** time December 31 at 24:00 plus the difference between DST and
** standard time, indicating DST all year.
*/
/*
** In the current implementation, "tzset()" refuses to deal with files that
** exceed any of the limits below.
*/
#ifndef TZ_MAX_TIMES
#define TZ_MAX_TIMES 1200
#endif /* !defined TZ_MAX_TIMES */
#ifndef TZ_MAX_TYPES
/* This must be at least 17 for Europe/Samara and Europe/Vilnius. */
#define TZ_MAX_TYPES 256 /* Limited by what (unsigned char)'s can hold */
#endif /* !defined TZ_MAX_TYPES */
#ifndef TZ_MAX_CHARS
#define TZ_MAX_CHARS 50 /* Maximum number of abbreviation characters */
/* (limited by what unsigned chars can hold) */
#endif /* !defined TZ_MAX_CHARS */
#ifndef TZ_MAX_LEAPS
#define TZ_MAX_LEAPS 50 /* Maximum number of leap second corrections */
#endif /* !defined TZ_MAX_LEAPS */
#define SECSPERMIN 60
#define MINSPERHOUR 60
#define HOURSPERDAY 24
#define DAYSPERWEEK 7
#define DAYSPERNYEAR 365
#define DAYSPERLYEAR 366
#define SECSPERHOUR (SECSPERMIN * MINSPERHOUR)
#define SECSPERDAY ((int_fast32_t) SECSPERHOUR * HOURSPERDAY)
#define MONSPERYEAR 12
#define TM_SUNDAY 0
#define TM_MONDAY 1
#define TM_TUESDAY 2
#define TM_WEDNESDAY 3
#define TM_THURSDAY 4
#define TM_FRIDAY 5
#define TM_SATURDAY 6
#define TM_JANUARY 0
#define TM_FEBRUARY 1
#define TM_MARCH 2
#define TM_APRIL 3
#define TM_MAY 4
#define TM_JUNE 5
#define TM_JULY 6
#define TM_AUGUST 7
#define TM_SEPTEMBER 8
#define TM_OCTOBER 9
#define TM_NOVEMBER 10
#define TM_DECEMBER 11
#define TM_YEAR_BASE 1900
#define EPOCH_YEAR 1970
#define EPOCH_WDAY TM_THURSDAY
#define isleap(y) (((y) % 4) == 0 && (((y) % 100) != 0 || ((y) % 400) == 0))
/*
** Since everything in isleap is modulo 400 (or a factor of 400), we know that
** isleap(y) == isleap(y % 400)
** and so
** isleap(a + b) == isleap((a + b) % 400)
** or
** isleap(a + b) == isleap(a % 400 + b % 400)
** This is true even if % means modulo rather than Fortran remainder
** (which is allowed by C89 but not C99).
** We use this to avoid addition overflow problems.
*/
#define isleap_sum(a, b) isleap((a) % 400 + (b) % 400)
#endif /* !defined TZFILE_H */