Updating our timezone code in the back branches
When I updated our copy of the IANA timezone library back in March
(commit 1c1a7cbd6), I noted that we ought to consider back-patching
those changes once they'd settled out in HEAD. Now that the code
has survived a couple of months of beta testing, I think it is time
to do that.
I went through the IANA announcement archives
http://mm.icann.org/pipermail/tz-announce/
to get a summary of what's changed since the tzcode 2010c release
that we last synced with. Attached is a list of code changes that
seem potentially significant to us. There are at least two ticking
time bombs in there, namely zic feature additions that IANA has not
yet started to use in the tzdata files, but presumably will start
using at some point, else why would they put them in? (These are
the extension to allow four DST transitions per year and the addition
of %z escapes in TZ abbreviations.) Whenever they do start using them,
we'll be unable to apply tzdata updates to unpatched back branches,
because our old copy of zic will fail to compile the tzdata files.
There are also several bug fixes that affect interpretation of dates after
2037, a year that's getting closer all the time. And there are some
changes that affect reading of zic data files, which could affect
unpatched back branches that are built with --with-system-tzdata,
since those might be fed updated data files even if we do nothing.
So I think it behooves us to apply these changes to the back branches
while we can still do it in a leisurely fashion, rather than waiting
until our hands are forced. I'd like to do it in the next week or so
so that we can get in a little bit of buildfarm and manual testing
before the next set of back-branch releases in August.
Thoughts, objections?
regards, tom lane
tzcode release 2013a
The zone offset at the end of version-2-format zone files is now
allowed to be 24:00, as per POSIX.1-2008.
Fix zic bug that mishandled Egypt's 2010 changes (this also affected
the data).
2013e
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.
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.
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.
2014b
'zic' and 'localtime' no longer reject locations needing four
transitions per year for the forseeable future. (Needed for
planned changes to make Antarctica/Troll zone more accurate)
2014c
zic now generates transitions for minimum time values, eliminating
guesswork when handling low-valued time stamps.
2015f
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.
zdump and zic no longer warn about valid time zone abbreviations
like '-05'. (We were forced to apply this change already, cf
221619ad6)
localtime no longer mishandles America/Anchorage after 2037.
not yet applied to PG:
2016e
zic now outputs a dummy transition at time 2**31 - 1 in zones
whose POSIX-style TZ strings contain a '<'. This mostly works
around Qt bug 53071 <https://bugreports.qt.io/browse/QTBUG-53071>.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jul 18, 2016 at 9:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
When I updated our copy of the IANA timezone library back in March
(commit 1c1a7cbd6), I noted that we ought to consider back-patching
those changes once they'd settled out in HEAD. Now that the code
has survived a couple of months of beta testing, I think it is time
to do that.I went through the IANA announcement archives
http://mm.icann.org/pipermail/tz-announce/
to get a summary of what's changed since the tzcode 2010c release
that we last synced with. Attached is a list of code changes that
seem potentially significant to us. There are at least two ticking
time bombs in there, namely zic feature additions that IANA has not
yet started to use in the tzdata files, but presumably will start
using at some point, else why would they put them in? (These are
the extension to allow four DST transitions per year and the addition
of %z escapes in TZ abbreviations.) Whenever they do start using them,
we'll be unable to apply tzdata updates to unpatched back branches,
because our old copy of zic will fail to compile the tzdata files.There are also several bug fixes that affect interpretation of dates after
2037, a year that's getting closer all the time. And there are some
changes that affect reading of zic data files, which could affect
unpatched back branches that are built with --with-system-tzdata,
since those might be fed updated data files even if we do nothing.So I think it behooves us to apply these changes to the back branches
while we can still do it in a leisurely fashion, rather than waiting
until our hands are forced. I'd like to do it in the next week or so
so that we can get in a little bit of buildfarm and manual testing
before the next set of back-branch releases in August.Thoughts, objections?
This seems reasonable. Except the 2016e one which hasn't seen master yet.
But it would definitely make sense to try to get 2016e into 9.6 ASAP, so we
can get it into the next beta/rc (not the one on it's way now, but the one
after that).
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Mon, Jul 18, 2016 at 8:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
There are also several bug fixes that affect interpretation of dates after
2037, a year that's getting closer all the time.
Does this represent a data incompatibility for databases that could
contain such dates already? That is, would this be changing the dates
their database contains?
We don't really have a solution for that kind of change but we should
highlight it fairly prominently and it would be nice if we gave people
a query that would search for any affected dates in a column.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
On Mon, Jul 18, 2016 at 9:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
So I think it behooves us to apply these changes to the back branches
while we can still do it in a leisurely fashion, rather than waiting
until our hands are forced. I'd like to do it in the next week or so
so that we can get in a little bit of buildfarm and manual testing
before the next set of back-branch releases in August.
This seems reasonable. Except the 2016e one which hasn't seen master yet.
But it would definitely make sense to try to get 2016e into 9.6 ASAP, so we
can get it into the next beta/rc (not the one on it's way now, but the one
after that).
I think that the 2016e change is not actually relevant to us; it's just
introducing a no-op DST transition into the data files in 2037. If our
version of zic were being used to produce zone files that Qt would read,
it might be important, but that seems pretty unlikely. So we should sync
it eventually but I'm not in much of a hurry.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Greg Stark <stark@mit.edu> writes:
On Mon, Jul 18, 2016 at 8:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
There are also several bug fixes that affect interpretation of dates after
2037, a year that's getting closer all the time.
Does this represent a data incompatibility for databases that could
contain such dates already? That is, would this be changing the dates
their database contains?
Hard to say. Those bugs might affect the way a stored timestamp would be
printed, but I don't really care to do the legwork that would be needed
to identify exactly what the consequences would be. In practice, I doubt
that the effects would be much different from a change in DST law that
might happen between now and 2037 --- anybody who's predicting now what
their local DST laws will be by then is pretty far out on a limb anyway :-(
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers