aboutsummaryrefslogtreecommitdiff
path: root/src/timezone/strftime.c
Commit message (Collapse)AuthorAge
* Sync our copy of the timezone library with IANA release tzcode2016c.Tom Lane2016-03-28
| | | | | | | | | | | | | | | | | 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.
* Remove cvs keywords from all files.Magnus Hagander2010-09-20
|
* Sync timezone code with tzcode 2010c from the Olson group. This fixes someTom Lane2010-03-11
| | | | | | | | | | corner cases that come up in certain timezones (apparently, only those with lots and lots of distinct TZ transition rules, as far as I can gather from a quick scan of their archives). Per suggestion from Jeevan Chalke. Back-patch to 8.4. Possibly we need to push this into earlier releases as well, but I'm hesitant to update them to the 64-bit tzcode without more thought and testing.
* 8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef listBruce Momjian2009-06-11
| | | | provided by Andrew.
* Fix function prototype to silence compiler warnings.Magnus Hagander2008-02-19
|
* Update timezone code to track the upstream changes since 2003. In particularTom Lane2008-02-16
| | | | | | | | this adds support for 64-bit tzdata files, which is needed to support DST calculations beyond 2038. Add a regression test case to give some minimal confidence that that really works. Heikki Linnakangas
* Remove 576 references of include files that were not needed.Bruce Momjian2006-07-14
|
* Revert part of recent include patch not ready for application.Bruce Momjian2006-07-14
|
* Add additional includes needed on some platforms.Bruce Momjian2006-07-14
|
* Standard pgindent run for 8.1.Bruce Momjian2005-10-15
|
* Cosmetic improvements to the timezone code: remove the use of theNeil Conway2005-06-20
| | | | | 'register' qualifier, make some function declarations more consistent, and so on.
* Attached patch gets rid of the global timezone in the following steps:Bruce Momjian2005-04-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | * Changes the APIs to the timezone functions to take a pg_tz pointer as an argument, representing the timezone to use for the selected operation. * Adds a global_timezone variable that represents the current timezone in the backend as set by SET TIMEZONE (or guc, or env, etc). * Implements a hash-table cache of loaded tables, so we don't have to read and parse the TZ file everytime we change a timezone. While not necesasry now (we don't change timezones very often), I beleive this will be necessary (or at least good) when "multiple timezones in the same query" is eventually implemented. And code-wise, this was the time to do it. There are no user-visible changes at this time. Implementing the "multiple zones in one query" is a later step... This also gets rid of some of the cruft needed to "back out a timezone change", since we previously couldn't check a timezone unless it was activated first. Passes regression tests on win32, linux (slackware 10) and solaris x86. Magnus Hagander
* Pgindent run for 8.0.Bruce Momjian2004-08-29
|
* Adjust our timezone library to use pg_time_t (typedef'd as int64) inTom Lane2004-06-03
| | | | | | | | | | | | | | | | | | | place of time_t, as per prior discussion. The behavior does not change on machines without a 64-bit-int type, but on machines with one, which is most, we are rid of the bizarre boundary behavior at the edges of the 32-bit-time_t range (1901 and 2038). The system will now treat times over the full supported timestamp range as being in your local time zone. It may seem a little bizarre to consider that times in 4000 BC are PST or EST, but this is surely at least as reasonable as propagating Gregorian calendar rules back that far. I did not modify the format of the zic timezone database files, which means that for the moment the system will not know about daylight-savings periods outside the range 1901-2038. Given the way the files are set up, it's not a simple decision like 'widen to 64 bits'; we have to actually think about the range of years that need to be supported. We should probably inquire what the plans of the upstream zic people are before making any decisions of our own.
* pgindent did a pretty awful job on the timezone code, particularly withTom Lane2004-05-21
| | | | respect to doubly-starred comment blocks. Do some manual cleanup.
* Pgindent timezone file, per request from Tom.Bruce Momjian2004-05-21
|
* Integrate src/timezone library for all platforms. There is more we canTom Lane2004-05-21
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.