11 Commits (2f67722dda9a46e82bad6807a12401dd7839910c)

Author	SHA1	Message	Date
Bruce Momjian	e0522505bd	Remove 576 references of include files that were not needed.	19 years ago
Bruce Momjian	51e8882197	Revert part of recent include patch not ready for application.	19 years ago
Bruce Momjian	03c2e5924e	Add additional includes needed on some platforms.	19 years ago
Bruce Momjian	1dc3498251	Standard pgindent run for 8.1.	20 years ago
Neil Conway	0b62bbe086	Cosmetic improvements to the timezone code: remove the use of the ... 'register' qualifier, make some function declarations more consistent, and so on.	21 years ago
Bruce Momjian	aa8bdab272	Attached patch gets rid of the global timezone in the following steps: ... * 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	21 years ago
Bruce Momjian	b6b71b85bc	Pgindent run for 8.0.	21 years ago
Tom Lane	921d749bd4	Adjust our timezone library to use pg_time_t (typedef'd as int64) in ... 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.	22 years ago
Tom Lane	d584db6086	pgindent did a pretty awful job on the timezone code, particularly with ... respect to doubly-starred comment blocks. Do some manual cleanup.	22 years ago
Bruce Momjian	0a19fb42c2	Pgindent timezone file, per request from Tom.	22 years ago
Tom Lane	63bd0db121	Integrate src/timezone library for all platforms. There is more we can ... 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.	22 years ago