summaryrefslogtreecommitdiff
path: root/src/timezone/Makefile
Commit message (Collapse)AuthorAgeFilesLines
* Update time zone data files to tzdata release 2021a.Tom Lane2021-01-241-1/+2
| | | | | | | | DST law changes in Russia (Volgograd zone) and South Sudan. Historical corrections for Australia, Bahamas, Belize, Bermuda, Ghana, Israel, Kenya, Nigeria, Palestine, Seychelles, and Vanuatu. Notably, the Australia/Currie zone has been corrected to the point where it is identical to Australia/Hobart.
* Sync our copy of the timezone library with IANA release tzcode2020c.Tom Lane2020-10-161-1/+1
| | | | | | | | | | | | | | | This changes zic's default output format from "-b fat" to "-b slim". We were already using "slim" in v13/HEAD, so those branches drop the explicit -b switch in the Makefiles. Instead, add an explicit "-b fat" in v12 and before, so that we don't change the output file format in those branches. (This is perhaps excessively conservative, but we decided not to do so in a12079109, and I'll stick with that.) Other non-cosmetic changes are to drop support for zic's long-obsolete "-y" switch, and to ensure that strftime() does not change errno unless it fails. As usual with tzcode changes, back-patch to all supported branches.
* Remove support for timezone "posixrules" file.Tom Lane2020-06-291-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The IANA tzcode library has a feature to read a time zone file named "posixrules" and apply the daylight-savings transition dates and times therein, when it is given a POSIX-style time zone specification that lacks an explicit transition rule. However, there's a problem with that code: it doesn't work for dates past the Y2038 time_t rollover. (Effectively, all times beyond that point are treated as standard time.) The IANA crew regard this feature as legacy, so their plan is to remove it not fix it. The time frame in which that will happen is unclear, but presumably it'll happen well before 2038. Moreover, effective with the next IANA data update (probably this fall), the recommended default will be to not install a "posixrules" file in the first place. The time frame in which tzdata packagers might adopt that suggestion is likewise unclear, but at least some platforms will probably do it in the next year or so. While we could ignore that recommendation so far as PG-supplied tzdata trees are concerned, builds using --with-system-tzdata will be subject to whatever the platform's tzdata packager decides to do. Thus, whether or not we do anything, some increasing fraction of Postgres users will be exposed to the behavior observed when there is no "posixrules" file; and if we do nothing, we'll have essentially no control over the timing of that change. The best thing to do to ameliorate the uncertainty seems to be to proactively remove the posixrules-reading feature. If we do that in a scheduled release then at least we can release-note the behavioral change, rather than having users be surprised by it after a routine tzdata update. The change in question is fairly minor anyway: to be affected, you have to be using a POSIX-style timezone spec, it has to not have an explicit rule, and it has to not be one of the four traditional continental-USA zone names (EST5EDT, CST6CDT, MST7MDT, or PST8PDT), as those are special-cased. Since the default "posixrules" file provides USA DST rules, the number of people who are likely to find such a zone spec useful is probably quite small. Moreover, the fallback behavior with no explicit rule and no "posixrules" file is to apply current USA rules, so the only thing that really breaks is the DST transitions in years before 2007 (and you get the countervailing fix that transitions after 2038 will be applied). Now, some installations might have replaced the "posixrules" file, allowing e.g. EU rules to be applied to a POSIX-style timezone spec. That won't work anymore. But it's not exactly clear why this solution would be preferable to using a regular named zone. In any case, given the Y2038 issue, we need to be pushing users to stop depending on this. Back-patch into v13; it hasn't been released yet, so it seems OK to change its behavior. (Personally I think we ought to back-patch further, but I've been outvoted.) Discussion: https://postgr.es/m/1390.1562258309@sss.pgh.pa.us Discussion: https://postgr.es/m/20200621211855.6211-1-eggert@cs.ucla.edu
* Dial back -Wimplicit-fallthrough to level 3Alvaro Herrera2020-05-131-5/+0
| | | | | | | | | The additional pain from level 4 is excessive for the gain. Also revert all the source annotation changes to their original wordings, to avoid back-patching pain. Discussion: https://postgr.es/m/31166.1589378554@sss.pgh.pa.us
* Add -Wimplicit-fallthrough to CFLAGS and CXXFLAGSAlvaro Herrera2020-05-121-0/+5
| | | | | | | | | | | | | | | Use it at level 4, a bit more restrictive than the default level, and tweak our commanding comments to FALLTHROUGH. (However, leave zic.c alone, since it's external code; to avoid the warnings that would appear there, change CFLAGS for that file in the Makefile.) Author: Julien Rouhaud <rjuju123@gmail.com> Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/20200412081825.qyo5vwwco3fv4gdo@nol Discussion: https://postgr.es/m/flat/E1fDenm-0000C8-IJ@gemulon.postgresql.org
* Split all OBJS style lines in makefiles into one-line-per-entry style.Andres Freund2019-11-051-2/+7
| | | | | | | | | | | | | | | When maintaining or merging patches, one of the most common sources for conflicts are the list of objects in makefiles. Especially when the split across lines has been changed on both sides, which is somewhat common due to attempting to stay below 80 columns, those conflicts are unnecessarily laborious to resolve. By splitting, and alphabetically sorting, OBJS style lines into one object per line, conflicts should be less frequent, and easier to resolve when they still occur. Author: Andres Freund Discussion: https://postgr.es/m/20191029200901.vww4idgcxv74cwes@alap3.anarazel.de
* Use zic's new "-b slim" option to generate smaller timezone files.Tom Lane2019-08-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | IANA tzcode release 2019b adds an option that tells zic not to emit the old 32-bit section of the timezone files, and to skip some other space-wasting hacks needed for compatibility with old timezone client libraries. Since we only expect our own code to use the timezone data we install, and our code is up-to-date with 2019b, there's no apparent reason not to generate the smallest possible files. Unfortunately, while the individual zone files do get significantly smaller in many cases, they were not that big to begin with; which means that no real space savings ensues on filesystems that don't optimize small files. (For instance, on ext4 with 4K block size, "du" says the installed timezone tree is the same size as before.) Still, it seems worth making the change, if only because this is presumably the wave of the future. At the very least, we'll save some cycles while reading a zone file. But given the marginal value and the fact that this is a new code path, it doesn't seem worth the risk of back-patching this change into stable branches. Hence, unlike most of our timezone-related changes, apply to HEAD only. Discussion: https://postgr.es/m/24998.1563403327@sss.pgh.pa.us
* Sync our copy of the timezone library with IANA release tzcode2019a.Tom Lane2019-04-261-1/+4
| | | | | | | | | | | | | | | | | | | | | | This corrects a small bug in zic that caused it to output an incorrect year-2440 transition in the Africa/Casablanca zone. More interestingly, zic has grown a "-r" option that limits the range of zone transitions that it will put into the output files. That might be useful to people who don't like the weird GMT offsets that tzdb likes to use for very old dates. It appears that for dates before the cutoff time specified with -r, zic will use the zone's standard-time offset as of the cutoff time. So for example one might do make install ZIC_OPTIONS='-r @-1893456000' to cause all dates before 1910-01-01 to be treated as though 1910 standard time prevailed indefinitely far back. (Don't blame me for the unfriendly way of specifying the cutoff time --- it's seconds since or before the Unix epoch. You can use extract(epoch ...) to calculate it.) As usual, back-patch to all supported branches.
* Replace raw timezone source data with IANA's new compact format.Tom Lane2017-11-251-4/+2
| | | | | | | | | | | | | | | Traditionally IANA has distributed their timezone data in pure source form, replete with extensive historical comments. As of release 2017c, they've added a compact single-file format that omits comments and abbreviates command keywords. This form is way shorter than the pure source, even before considering its allegedly better compressibility. Hence, let's distribute the data in that form rather than pure source. I'm pushing this now, rather than at the next timezone database update, so that it's easy to confirm that this data file produces compiled zic output that's identical to what we were getting before. Discussion: https://postgr.es/m/1915.1511210334@sss.pgh.pa.us
* Sync our copy of the timezone library with IANA release tzcode2016c.Tom Lane2016-03-281-1/+1
| | | | | | | | | | | | | | | | | We hadn't done this in about six years, which proves to have been a mistake because there's been a lot of code churn upstream, making the merge rather painful. But putting it off any further isn't going to lessen the pain, and there are at least two incompatible changes that we need to absorb before someone starts complaining that --with-system-tzdata doesn't work at all on their platform, or we get blindsided by a tzdata release that our out-of-date zic can't compile. Last week's "time zone abbreviation differs from POSIX standard" mess was a wake-up call in that regard. This is a sufficiently large patch that I'm afraid to back-patch it immediately, though the foregoing considerations imply that we probably should do so eventually. For the moment, just put it in HEAD so that it can get some testing. Maybe we can wait till the end of the 9.6 beta cycle before deeming it okay.
* Finish adding file version information to installed Windows binaries.Noah Misch2014-08-181-1/+4
| | | | | | | In support of this, have the MSVC build follow GNU make in preferring GNUmakefile over Makefile when a directory contains both. Michael Paquier, reviewed by MauMau.
* Ooops, forgot to remove solar87 and friends from src/timezone/Makefile.Tom Lane2014-02-141-1/+1
| | | | Per buildfarm.
* Rename 'gmake' to 'make' in docs and recommended commandsBruce Momjian2014-02-121-2/+2
| | | | This simplifies the docs and makes it easier to cut/paste command lines.
* Semi-automatically detect changes in timezone abbreviations.Tom Lane2013-03-231-1/+6
| | | | | | | | | | | | | Add an option to zic.c to dump out all non-obsolete timezone abbreviations defined in the Olson database. Comparing this list to its previous state will clue us in when something happens that we may need to account for in the tznames/ time zone abbreviation lists. The README file's previous exhortation to "just grep for differences" was completely useless advice, in my now-considerable experience; but maybe this will be a bit more useful. As a starting point I built the same list from the tzdata files as they existed in 2006, which is committed here as known_abbrevs.txt. Comparison indeed turned up quite a few changes we had neglected to account for, which I will commit separately.
* Improved parallel make supportPeter Eisentraut2010-11-121-2/+2
| | | | | | | | Replace for loops in makefiles with proper dependencies. Parallel make can now span across directories. Also, make -k and make -q work properly. GNU make 3.80 or newer is now required.
* Remove cvs keywords from all files.Magnus Hagander2010-09-201-1/+1
|
* Split the LDFLAGS make variable into two parts: LDFLAGS is now used forTom Lane2010-07-051-2/+2
| | | | | | | | | | | | | linking both executables and shared libraries, and we add on LDFLAGS_EX when linking executables or LDFLAGS_SL when linking shared libraries. This provides a significantly cleaner way of dealing with link-time switches than the former behavior. Also, make sure that the various platform-specific %.so: %.o rules incorporate LDFLAGS and LDFLAGS_SL; most of them missed that before. (I did not add these variables for the platforms that invoke $(LD) directly, however. It's not clear if we can do that safely, since for the most part we assume these variables use CC command-line syntax.) Per gripe from Aaron Swenson and subsequent investigation.
* Update of install-sh, mkinstalldirs, and associated configuryPeter Eisentraut2009-08-261-2/+2
| | | | | | | | | | | | | | Update install-sh to that from Autoconf 2.63, plus our Darwin-specific changes (which I simplified a bit). install-sh is now able to install multiple files in one run, so we could simplify our makefiles sometime. install-sh also now has a -d option to create directories, so we don't need mkinstalldirs anymore. Use AC_PROG_MKDIR_P in configure.in, so we can use mkdir -p when available instead of install-sh -d. For consistency with the rest of the world, the corresponding make variable has been renamed from $(mkinstalldirs) to $(MKDIR_P).
* Fix new timezone cross-compile rule to avoid a bug in gmake 3.78.1;Bruce Momjian2009-01-061-2/+10
| | | | document change.
* When cross-compiling, allow and require an external zic program to be usedPeter Eisentraut2009-01-051-2/+2
| | | | | | when --with-system-tzdata is not used. initial patch by Richard Evans
* More refactoring, so that the SUBSYS.o rules are now all in one place.Peter Eisentraut2008-02-191-6/+3
|
* Adjust with-system-tzdata patch to not attempt to install a symlink,Tom Lane2007-08-251-6/+13
| | | | | | but just hardwire the specified timezone database path into the executable. Per discussion, this avoids some packaging disadvantages of using a symlink.
* Add configure option --with-system-tzdata to use operating system time zonePeter Eisentraut2007-08-201-1/+7
| | | | database.
* Arrange to install a "posixrules" entry in our timezone database, so thatTom Lane2007-03-141-2/+6
| | | | | | | | | | | | | POSIX-style timezone specs that don't exactly match any database entry will be treated as having correct USA DST rules. Also, document that this can be changed if you want to use some other DST rules with a POSIX zone spec. We could consider changing localtime.c's TZDEFRULESTRING, but since that facility can only deal with one DST transition rule, it seems fairly useless now; might as well just plan to override it using a "posixrules" entry. Backpatch as far as 8.0. There isn't much we can do in 7.x ... either your libc gets it right, or it doesn't.
* Replace useless uses of := by = in makefiles.Peter Eisentraut2007-02-091-5/+3
|
* Remove hard-wired lists of timezone abbreviations in favor of providingTom Lane2006-07-251-1/+3
| | | | | | | | | configuration files that can be altered by a DBA. The australian_timezones GUC setting disappears, replaced by a timezone_abbreviations setting (set this to 'Australia' to get the effect of australian_timezones). The list of zone names defined by default has undergone a bit of cleanup, too. Documentation still needs some work --- in particular, should we fix Table B-4, or just get rid of it? Joachim Wieland, with some editorializing by moi.
* Allow installation into directories containing spaces in the name.Peter Eisentraut2005-12-091-3/+6
|
* Complete zic patch backout by removing NO_PGPORT workaround.Bruce Momjian2005-07-061-2/+2
|
* Reverse out because the lack of using pgport in timezone/ is causingBruce Momjian2005-07-061-13/+4
| | | | | | | | | | problems: --------------------------------------------------------------------------- Support cross compilation by compiling "zic" with a native compiler. This relies on the output of zic being platform independent, but that is currently the case.
* Restructure zic #define fprintf checks to use a NO_PGPORT macro instead.Bruce Momjian2005-07-041-2/+2
|
* Fix build break for out of tree (vpath) builds, induced by recent zicNeil Conway2005-07-041-2/+2
| | | | changes.
* Support cross compilation by compiling "zic" with a native compiler. ThisPeter Eisentraut2005-07-031-4/+13
| | | | | relies on the output of zic being platform independent, but that is currently the case.
* make clean must remove zic$(X) for Windows, per Magnus.Tom Lane2004-12-311-2/+2
|
* Make libpgport be front-end only and make libpgport_srv be a backendBruce Momjian2004-10-041-8/+5
| | | | | library that uses palloc, ereport, etc. This simplifies the makefiles for client applications.
* More Win32 zic build cleanups now that we have symlinks, it needs help.Bruce Momjian2004-08-081-3/+3
|
* Another zic cleanup .Bruce Momjian2004-08-081-1/+3
|
* Link in dirmod specially for zic so it works on Win32.Bruce Momjian2004-08-081-3/+6
|
* Seems we forgot the installdirs target in this makefile.Tom Lane2004-05-281-1/+4
|
* Fix to install correctly in vpath build case.Tom Lane2004-05-221-2/+2
|
* Integrate src/timezone library for all platforms. There is more we canTom Lane2004-05-211-8/+10
| | | | | | and should do now that we control our own destiny for timezone handling, but this commit gets the bulk of the picayune diffs in place. Magnus Hagander and Tom Lane.
* Update Makefile dependencies for Win32 timezones, per Claudio.Bruce Momjian2004-05-181-3/+3
|
* Reorganize code to allow path-relative installs.Bruce Momjian2004-05-171-3/+1
| | | | | | | Create new get_* functions to access compiled-in paths and adjust if relative installs are to be used. Clean up substitute_libpath_macro() code.
* Fix zic compiler to use pg version.Bruce Momjian2004-04-301-3/+3
| | | | Move timezone database to share/timezone.
* Allow build of timezone database on unix.Bruce Momjian2004-04-301-2/+2
|
* More timezone build adjustments.Bruce Momjian2004-04-301-2/+2
|
* More cleanups for USE_PGTZ.Bruce Momjian2004-04-301-2/+2
|
* Allow timezone to compile under Unix by blocking 'timezone' conflict withBruce Momjian2004-04-301-2/+5
| | | | | | | system headers. Allow system to find timezone database by pasing pkglibdir into the binary via a define.
* Integrate timezone library to be called only from Win32.Bruce Momjian2004-04-301-5/+7
| | | | Timezone code backend integration done by Magnus Hagander.
* Add Olson's public domain timezone library to src/timezone.Bruce Momjian2004-04-301-0/+33