Source-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[src/trunk]: src/lib/libc/time merge 2015f
details: https://anonhg.NetBSD.org/src/rev/2ec017f15cf0
branches: trunk
changeset: 809996:2ec017f15cf0
user: christos <christos%NetBSD.org@localhost>
date: Thu Aug 13 11:21:18 2015 +0000
description:
merge 2015f
diffstat:
lib/libc/time/Makefile | 10 +-
lib/libc/time/NEWS | 66 ++++
lib/libc/time/Theory | 717 +++++++++++++++++++++++----------------------
lib/libc/time/difftime.c | 61 ++-
lib/libc/time/localtime.c | 88 ++--
lib/libc/time/private.h | 28 +-
lib/libc/time/strftime.c | 18 +-
lib/libc/time/tz-art.htm | 52 +-
lib/libc/time/tz-link.htm | 103 +++---
lib/libc/time/zdump.c | 32 +-
lib/libc/time/zic.8 | 62 ++-
lib/libc/time/zic.c | 156 ++++++---
12 files changed, 762 insertions(+), 631 deletions(-)
diffs (truncated from 2473 to 300 lines):
diff -r 1923334880bb -r 2ec017f15cf0 lib/libc/time/Makefile
--- a/lib/libc/time/Makefile Thu Aug 13 10:36:38 2015 +0000
+++ b/lib/libc/time/Makefile Thu Aug 13 11:21:18 2015 +0000
@@ -5,7 +5,7 @@
PACKAGE= tzcode
# Version numbers of the code and data distributions.
-VERSION= 2015e
+VERSION= 2015f
# Email address for bug reports.
BUGEMAIL= tz%iana.org@localhost
@@ -102,7 +102,6 @@
# Add the following to the end of the "CFLAGS=" line as needed.
# -DBIG_BANG=-9999999LL if the Big Bang occurred at time -9999999 (see zic.c)
-# -DHAVE_ADJTIME=0 if 'adjtime' does not exist (SVR0?)
# -DHAVE_DOS_FILE_NAMES if file names have drive specifiers etc. (MS-DOS)
# -DHAVE_GETTEXT=1 if 'gettext' works (GNU, Linux, Solaris); also see LDLIBS
# -DHAVE_INCOMPATIBLE_CTIME_R=1 if your system's time.h declares
@@ -113,10 +112,6 @@
# -DHAVE_LOCALTIME_RZ=0 if you do not want zdump to use localtime_rz
# This defaults to 1 if a working localtime_rz seems to be available.
# localtime_rz can make zdump significantly faster, but is nonstandard.
-# -DHAVE_SETTIMEOFDAY=0 if settimeofday does not exist (SVR0?)
-# -DHAVE_SETTIMEOFDAY=1 if settimeofday has just 1 arg (SVR4)
-# -DHAVE_SETTIMEOFDAY=2 if settimeofday uses 2nd arg (4.3BSD)
-# -DHAVE_SETTIMEOFDAY=3 if settimeofday ignores 2nd arg (4.4BSD)
# -DHAVE_STDINT_H=1 if you have a pre-C99 compiler with "stdint.h"
# -DHAVE_STRFTIME_L=1 if <time.h> declares locale_t and strftime_l
# This defaults to 0 if _POSIX_VERSION < 200809, 1 otherwise.
@@ -126,7 +121,6 @@
# -DHAVE_SYS_WAIT_H=0 if your compiler lacks a "sys/wait.h"
# -DHAVE_TZSET=0 if your system lacks a tzset function
# -DHAVE_UNISTD_H=0 if your compiler lacks a "unistd.h" (Microsoft C++ 7?)
-# -DHAVE_UTMPX_H=1 if your compiler has a "utmpx.h"
# -DNO_RUN_TIME_WARNINGS_ABOUT_YEAR_2000_PROBLEMS_THANK_YOU=1
# if you do not want run time warnings about formats that may cause
# year 2000 grief
@@ -148,7 +142,7 @@
# -DZIC_MAX_ABBR_LEN_WO_WARN=3
# (or some other number) to set the maximum time zone abbreviation length
# that zic will accept without a warning (the default is 6)
-# $(GCC_DEBUG_FLAGS) if you are using GCC and want lots of checking
+# $(GCC_DEBUG_FLAGS) if you are using recent GCC and want lots of checking
GCC_DEBUG_FLAGS = -Dlint -g3 -O3 -fno-common -fstrict-aliasing \
-Wall -Wextra \
-Wbad-function-cast -Wcast-align -Wdate-time \
diff -r 1923334880bb -r 2ec017f15cf0 lib/libc/time/NEWS
--- a/lib/libc/time/NEWS Thu Aug 13 10:36:38 2015 +0000
+++ b/lib/libc/time/NEWS Thu Aug 13 11:21:18 2015 +0000
@@ -1,5 +1,71 @@
News for the tz database
+Release 2015f - 2015-08-10 18:06:56 -0700
+
+ Changes affecting future time stamps
+
+ North Korea switches to +0830 on 2015-08-15. (Thanks to Steffen Thorsen.)
+ The abbreviation remains "KST". (Thanks to Robert Elz.)
+
+ Uruguay no longer observes DST. (Thanks to Steffen Thorsen
+ and Pablo Camargo.)
+
+ Changes affecting past and future time stamps
+
+ Moldova starts and ends DST at 00:00 UTC, not at 01:00 UTC.
+ (Thanks to Roman Tudos.)
+
+ Changes affecting data format and code
+
+ zic's '-y YEARISTYPE' option is no longer documented. The TYPE
+ field of a Rule line should now be '-'; the old values 'even',
+ 'odd', 'uspres', 'nonpres', 'nonuspres' were already undocumented.
+ Although the implementation has not changed, these features do not
+ work in the default installation, they are not used in the data,
+ and they are now considered obsolescent.
+
+ zic now checks that two rules don't take effect at the same time.
+ (Thanks to Jon Skeet and Arthur David Olson.) Constraints on
+ simultaneity are now documented.
+
+ The two characters '%z' in a zone format now stand for the UTC
+ offset, e.g., '-07' for seven hours behind UTC and '+0530' for
+ five hours and thirty minutes ahead. This better supports time
+ zone abbreviations conforming to POSIX.1-2001 and later.
+
+ Changes affecting installed data files
+
+ Comments for America/Halifax and America/Glace_Bay have been improved.
+ (Thanks to Brian Inglis.)
+
+ Data entries have been simplified for Atlantic/Canary, Europe/Simferopol,
+ Europe/Sofia, and Europe/Tallinn. This yields slightly smaller
+ installed data files for Europe/Simferopol and Europe/Tallinn.
+ It does not affect timestamps. (Thanks to Howard Hinnant.)
+
+ Changes affecting code
+
+ zdump and zic no longer warn about valid time zone abbreviations
+ like '-05'.
+
+ Some Visual Studio 2013 warnings have been suppressed.
+ (Thanks to Kees Dekker.)
+
+ 'date' no longer sets the time of day and its -a, -d, -n and -t
+ options have been removed. Long obsolescent, the implementation
+ of these features had porting problems. Builders no longer need
+ to configure HAVE_ADJTIME, HAVE_SETTIMEOFDAY, or HAVE_UTMPX_H.
+ (Thanks to Kees Dekker for pointing out the problem.)
+
+ Changes affecting documentation
+
+ The Theory file mentions naming issues earlier, as these seem to be
+ poorly publicized (thanks to Gilmore Davidson for reporting the problem).
+
+ tz-link.htm mentions Time Zone Database Parser (thanks to Howard Hinnant).
+
+ Mention that Herbert Samuel introduced the term "Summer Time".
+
Release 2015e - 2015-06-13 10:56:02 -0700
diff -r 1923334880bb -r 2ec017f15cf0 lib/libc/time/Theory
--- a/lib/libc/time/Theory Thu Aug 13 10:36:38 2015 +0000
+++ b/lib/libc/time/Theory Thu Aug 13 11:21:18 2015 +0000
@@ -1,25 +1,379 @@
-This file is in the public domain, so clarified as of
-2009-05-17 by Arthur David Olson.
+Theory and pragmatics of the tz code and data
+
----- Outline -----
+ Scope of the tz database
+ Names of time zone rules
+ Time zone abbreviations
+ Accuracy of the tz database
Time and date functions
- Scope of the tz database
- Names of time zone rule files
- Time zone abbreviations
Calendrical issues
Time and time zones on Mars
------ Time and date functions -----
+
+----- Scope of the tz database -----
-These time and date functions are upwards compatible with those of POSIX,
-an international standard for UNIX-like systems.
-As of this writing, the current edition of POSIX is:
+The tz database attempts to record the history and predicted future of
+all computer-based clocks that track civil time. To represent this
+data, the world is partitioned into regions whose clocks all agree
+about time stamps that occur after the somewhat-arbitrary cutoff point
+of the POSIX Epoch (1970-01-01 00:00:00 UTC). For each such region,
+the database records all known clock transitions, and labels the region
+with a notable location. Although 1970 is a somewhat-arbitrary
+cutoff, there are significant challenges to moving the cutoff earlier
+even by a decade or two, due to the wide variety of local practices
+before computer timekeeping became prevalent.
+
+Clock transitions before 1970 are recorded for each such location,
+because most systems support time stamps before 1970 and could
+misbehave if data entries were omitted for pre-1970 transitions.
+However, the database is not designed for and does not suffice for
+applications requiring accurate handling of all past times everywhere,
+as it would take far too much effort and guesswork to record all
+details of pre-1970 civil timekeeping.
+
+As described below, reference source code for using the tz database is
+also available. The tz code is upwards compatible with POSIX, an
+international standard for UNIX-like systems. As of this writing, the
+current edition of POSIX is:
The Open Group Base Specifications Issue 7
IEEE Std 1003.1, 2013 Edition
<http://pubs.opengroup.org/onlinepubs/9699919799/>
+
+
+----- Names of time zone rules -----
+
+Each of the database's time zone rules has a unique name.
+Inexperienced users are not expected to select these names unaided.
+Distributors should provide documentation and/or a simple selection
+interface that explains the names; for one example, see the 'tzselect'
+program in the tz code. The Unicode Common Locale Data Repository
+<http://cldr.unicode.org/> contains data that may be useful for other
+selection interfaces.
+
+The time zone rule naming conventions attempt to strike a balance
+among the following goals:
+
+ * Uniquely identify every region where clocks have agreed since 1970.
+ This is essential for the intended use: static clocks keeping local
+ civil time.
+
+ * Indicate to experts where that region is.
+
+ * Be robust in the presence of political changes. For example, names
+ of countries are ordinarily not used, to avoid incompatibilities
+ when countries change their name (e.g. Zaire->Congo) or when
+ locations change countries (e.g. Hong Kong from UK colony to
+ China).
+
+ * Be portable to a wide variety of implementations.
+
+ * Use a consistent naming conventions over the entire world.
+
+Names normally have the form AREA/LOCATION, where AREA is the name
+of a continent or ocean, and LOCATION is the name of a specific
+location within that region. North and South America share the same
+area, 'America'. Typical names are 'Africa/Cairo', 'America/New_York',
+and 'Pacific/Honolulu'.
+
+Here are the general rules used for choosing location names,
+in decreasing order of importance:
+
+ Use only valid POSIX file name components (i.e., the parts of
+ names other than '/'). Do not use the file name
+ components '.' and '..'. Within a file name component,
+ use only ASCII letters, '.', '-' and '_'. Do not use
+ digits, as that might create an ambiguity with POSIX
+ TZ strings. A file name component must not exceed 14
+ characters or start with '-'. E.g., prefer 'Brunei'
+ to 'Bandar_Seri_Begawan'. Exceptions: see the discussion
+ of legacy names below.
+ A name must not be empty, or contain '//', or start or end with '/'.
+ Do not use names that differ only in case. Although the reference
+ implementation is case-sensitive, some other implementations
+ are not, and they would mishandle names differing only in case.
+ If one name A is an initial prefix of another name AB (ignoring case),
+ then B must not start with '/', as a regular file cannot have
+ the same name as a directory in POSIX. For example,
+ 'America/New_York' precludes 'America/New_York/Bronx'.
+ Uninhabited regions like the North Pole and Bouvet Island
+ do not need locations, since local time is not defined there.
+ There should typically be at least one name for each ISO 3166-1
+ officially assigned two-letter code for an inhabited country
+ or territory.
+ If all the clocks in a region have agreed since 1970,
+ don't bother to include more than one location
+ even if subregions' clocks disagreed before 1970.
+ Otherwise these tables would become annoyingly large.
+ If a name is ambiguous, use a less ambiguous alternative;
+ e.g. many cities are named San José and Georgetown, so
+ prefer 'Costa_Rica' to 'San_Jose' and 'Guyana' to 'Georgetown'.
+ Keep locations compact. Use cities or small islands, not countries
+ or regions, so that any future time zone changes do not split
+ locations into different time zones. E.g. prefer 'Paris'
+ to 'France', since France has had multiple time zones.
+ Use mainstream English spelling, e.g. prefer 'Rome' to 'Roma', and
+ prefer 'Athens' to the Greek 'Î?θήνα' or the Romanized 'AthÃna'.
+ The POSIX file name restrictions encourage this rule.
+ Use the most populous among locations in a zone,
+ e.g. prefer 'Shanghai' to 'Beijing'. Among locations with
+ similar populations, pick the best-known location,
+ e.g. prefer 'Rome' to 'Milan'.
+ Use the singular form, e.g. prefer 'Canary' to 'Canaries'.
+ Omit common suffixes like '_Islands' and '_City', unless that
+ would lead to ambiguity. E.g. prefer 'Cayman' to
+ 'Cayman_Islands' and 'Guatemala' to 'Guatemala_City',
+ but prefer 'Mexico_City' to 'Mexico' because the country
+ of Mexico has several time zones.
+ Use '_' to represent a space.
+ Omit '.' from abbreviations in names, e.g. prefer 'St_Helena'
+ to 'St._Helena'.
+ Do not change established names if they only marginally
+ violate the above rules. For example, don't change
+ the existing name 'Rome' to 'Milan' merely because
+ Milan's population has grown to be somewhat greater
+ than Rome's.
+ If a name is changed, put its old spelling in the 'backward' file.
+ This means old spellings will continue to work.
+
+The file 'zone1970.tab' lists geographical locations used to name time
+zone rules. It is intended to be an exhaustive list of names for
+geographic regions as described above; this is a subset of the names
+in the data. Although a 'zone1970.tab' location's longitude
+corresponds to its LMT offset with one hour for every 15 degrees east
+longitude, this relationship is not exact.
+
+Older versions of this package used a different naming scheme,
+and these older names are still supported.
+See the file 'backward' for most of these older names
+(e.g., 'US/Eastern' instead of 'America/New_York').
+The other old-fashioned names still supported are
+'WET', 'CET', 'MET', and 'EET' (see the file 'europe').
+
+Older versions of this package defined legacy names that are
+incompatible with the first rule of location names, but which are
+still supported. These legacy names are mostly defined in the file
+'etcetera'. Also, the file 'backward' defines the legacy names
+'GMT0', 'GMT-0', 'GMT+0' and 'Canada/East-Saskatchewan', and the file
+'northamerica' defines the legacy names 'EST5EDT', 'CST6CDT',
+'MST7MDT', and 'PST8PDT'.
+
+Excluding 'backward' should not affect the other data. If
Home |
Main Index |
Thread Index |
Old Index