summaryrefslogtreecommitdiff
path: root/src/timezone
Commit message (Collapse)AuthorAgeFilesLines
* Tweak dynahash.c to not allocate so many entries at once when dealingTom Lane2005-06-261-2/+2
| | | | | | with a table that has a small predicted size. Avoids wasting several hundred K on the timezone hash table, which is likely to have only one or a few entries, but the entries use up 10Kb apiece ...
* Cosmetic improvements to the timezone code: remove the use of theNeil Conway2005-06-206-201/+200
| | | | | 'register' qualifier, make some function declarations more consistent, and so on.
* Simplify uses of readdir() by creating a function ReadDir() thatTom Lane2005-06-191-18/+8
| | | | | | | includes error checking and an appropriate ereport(ERROR) message. This gets rid of rather tedious and error-prone manipulation of errno, as well as a Windows-specific bug workaround, at more than a dozen call sites. After an idea in a recent patch by Heikki Linnakangas.
* This patch makes it possible to use the full set of timezones when doingBruce Momjian2005-06-151-3/+1
| | | | | | | | | | | | | | | | | | "AT TIME ZONE", and not just the shorlist previously available. For example: SELECT CURRENT_TIMESTAMP AT TIME ZONE 'Europe/London'; works fine now. It will also obey whatever DST rules were in effect at just that date, which the previous implementation did not. It also supports the AT TIME ZONE on the timetz datatype. The whole handling of DST is a bit bogus there, so I chose to make it use whatever DST rules are in effect at the time of executig the query. not sure if anybody is actuallyi *using* timetz though, it seems pretty unpredictable just because of this... Magnus Hagander
* >> Do you agree that using a hashtable for it in general is a good ideaBruce Momjian2005-06-151-7/+12
| | | | | | | | | | | | | | | | | >> assuming this sideeffect is removed, though? > >I have no problem with the hashtable, only with preloading it with >everything. What I'd like to see is that the table inherited at fork() >contains just the data for the default timezone. (At least in the >normal case where that setting hasn't been changed since postmaster >start.) Here's a patch doing this. Changes score_timezone not to use pg_tzset(), and thus not loading all the zones in the cache. The actual timezone being picked will be set using set_global_timezone() which in turn calls pg_tzset() and loads it in the cache. Magnus Hagander
* Modify hash_search() API to prevent future occurrences of the errorTom Lane2005-05-291-4/+6
| | | | | | | | | | | | | spotted by Qingqing Zhou. The HASH_ENTER action now automatically fails with elog(ERROR) on out-of-memory --- which incidentally lets us eliminate duplicate error checks in quite a bunch of places. If you really need the old return-NULL-on-out-of-memory behavior, you can ask for HASH_ENTER_NULL. But there is now an Assert in that path checking that you aren't hoping to get that behavior in a palloc-based hash table. Along the way, remove the old HASH_FIND_SAVE/HASH_REMOVE_SAVED actions, which were not being used anywhere anymore, and were surely too ugly and unsafe to want to see revived again.
* More macro cleanups for date/time.Bruce Momjian2005-05-231-2/+2
|
* Attached patch gets rid of the global timezone in the following steps:Bruce Momjian2005-04-195-93/+185
| | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
* Properly undef _(x) gettext macro.Bruce Momjian2005-02-231-2/+2
|
* Use _() macro consistently rather than gettext(). Add translationBruce Momjian2005-02-221-1/+2
| | | | macros around strings that were missing them.
* Tag appropriate files for rc3PostgreSQL Daemon2004-12-312-4/+4
| | | | | | | | Also performed an initial run through of upgrading our Copyright date to extend to 2005 ... first run here was very simple ... change everything where: grep 1996-2004 && the word 'Copyright' ... scanned through the generated list with 'less' first, and after, to make sure that I only picked up the right entries ...
* make clean must remove zic$(X) for Windows, per Magnus.Tom Lane2004-12-311-2/+2
|
* Invent pg_next_dst_boundary() and rewrite DetermineLocalTimeZone() toTom Lane2004-11-011-1/+95
| | | | | | | | | | | | use it, as per my proposal of yesterday. This gives us a means of determining the zone offset to impute to an unlabeled timestamp that is both efficient and reliable, unlike all our previous tries involving mktime() and localtime(). The behavior for invalid or ambiguous times at a DST transition is fixed to be really and truly "assume standard time", fixing a bug that has come and gone repeatedly but was back again in 7.4. (There is some ongoing discussion about whether we should raise an error instead, but for the moment I'll make it do what it was previously intended to do.)
* Sync timezone data with latest zic database (dated Oct 11 2004).Tom Lane2004-10-248-64/+268
|
* Update RELEASE_CHANGES to mention updating the timezone database asTom Lane2004-10-241-1/+9
| | | | a routine part of release prep.
* 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.
* Remove inclusion of windows.h now that it is included in c.h, per ideaBruce Momjian2004-09-271-5/+1
| | | | from Peter.
* Use _timezone global on Cygwin instead of timezone.Bruce Momjian2004-09-081-6/+2
|
* Back out timezone detection patch. Tom already applied it.Bruce Momjian2004-09-021-105/+1
|
* This patch attempts to fix the issue with localized timezones onBruce Momjian2004-09-021-1/+105
| | | | | | | | | | | | | | | | | | | | Windows. Recap: When running on a localized windows version, the timezone name returned is also localized, and therefor does not match our lookup table. Solution: The registry contains both the name of the timezone in english and the localized name. The patch adds code to scan the registry for the localized name and gets the english name from that, and then rescans the table. I have tested this on a Swedish WinXP, and it works without problems. The registry layout is the same in Win2k, but I haven't specifically tested it. It's also the same on different languages but again only Swedish is tested. Magnus Hagander
* Add code to be able to match the timezone name on localized WindowsTom Lane2004-09-011-1/+108
| | | | systems. Magnus Hagander.
* Another pgindent run with lib typedefs added.Bruce Momjian2004-08-301-3/+3
|
* Pgindent run for 8.0.Bruce Momjian2004-08-295-294/+464
|
* Update copyright to 2004.Bruce Momjian2004-08-292-4/+4
|
* Fix function definition that somehow missed being ANSI-fied, and alignTom Lane2004-08-111-19/+2
| | | | | | it with previous prototype to suppress complaints from picky compilers, per report from Scott Bailey. Also, remove substitute strerror definition --- not needed, since we link this with libpgport.
* More Win32 zic build cleanups now that we have symlinks, it needs help.Bruce Momjian2004-08-082-5/+4
|
* 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
|
* Still another try at matching system timezone nicely. On non-WindowsTom Lane2004-07-311-56/+260
| | | | | | | | | | machines, break tie scores by preferring shorter zone names over longer; for names of equal length, prefer the alphabetically first name. This yields for example 'EST5EDT' not 'America/New_York' for US eastern time. On Windows, abandon the whole concept of inspecting the detailed behavior of the system TZ library, because it doesn't bear inspection :-(. Instead use a hardwired mapping table to select our zone name based on the result of strftime %Z output. Windows code from Magnus Hagander.
* Must guard against NULL return from localtime() when probing pre-1970Tom Lane2004-07-301-2/+13
| | | | dates. Per Magnus Hagander.
* Still another try at automatically detecting the best match in the zicTom Lane2004-07-221-64/+78
| | | | | | timezone database for the system behavior we find ourselves in. Scan backwards from current time and choose the zone that matches furthest back. As per discussion a week or so back.
* Add missing <getopt.h>, per Dann Corbit.Tom Lane2004-07-221-2/+5
|
* Check more test points (in fact, every week in 1970..2004) to get a moreTom Lane2004-07-101-77/+70
| | | | | | | | | | | accurate matching of our time zone to the system's zone. This method is able to distinguish Antarctica/Casey from Australia/Perth, as in Chris K-L's recent example; and it is not materially slower than before, because the extra checks generally don't get done against very many time zones. It seems possible that with this test we'd be able to correctly identify Windows timezones without looking at the timezone name, but I do not have the ability to try it.
* Adjust our timezone library to use pg_time_t (typedef'd as int64) inTom Lane2004-06-034-430/+101
| | | | | | | | | | | | | | | | | | | 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.
* Seems we forgot the installdirs target in this makefile.Tom Lane2004-05-281-1/+4
|
* Tweaks per discussion with Magnus: suppress chatter on unpatched MinGWTom Lane2004-05-251-1/+27
| | | | | systems, add verbose logging (at DEBUG4) to help identify why a given time zone is not matched.
* Add code to identify_system_timezone() to try all zones in the zicTom Lane2004-05-251-55/+216
| | | | | | | database, not just ones that we cons up POSIX names for. This looks grim but it seems to take less than a second even on a relatively slow machine, and since it only happens once during postmaster startup, that seems acceptable.
* Rewrite identify_system_timezone() to give it better-than-chance oddsTom Lane2004-05-241-78/+114
| | | | | | | of correctly identifying the system's daylight-savings transition rules. This still begs the question of how to look through the zic database to find a matching zone definition, but at least now we'll have some chance of recognizing the match when we find it.
* Seems we had the wrong sign convention for the default Etc/GMTx zoneTom Lane2004-05-231-3/+8
| | | | names. Per report from Alvaro.
* Use case-insensitive comparison so that explicitly setting timezone=unknownTom Lane2004-05-231-2/+2
| | | | | in postgresql.conf does the right thing. variable.c got this right, but not pgtz.c ...
* Fix to install correctly in vpath build case.Tom Lane2004-05-221-2/+2
|
* pgindent did a pretty awful job on the timezone code, particularly withTom Lane2004-05-217-396/+447
| | | | respect to doubly-starred comment blocks. Do some manual cleanup.
* Pgindent timezone file, per request from Tom.Bruce Momjian2004-05-219-1771/+2243
|
* Integrate src/timezone library for all platforms. There is more we canTom Lane2004-05-2113-1327/+1019
| | | | | | 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.
* Allow zic to compile by defining a "" value for my_exec_path. It isn'tBruce Momjian2004-05-191-0/+6
| | | | used by zic anyway.
* Update Makefile dependencies for Win32 timezones, per Claudio.Bruce Momjian2004-05-182-3/+4
|
* Clean up some relative path install issues with Claudio's help.Bruce Momjian2004-05-181-4/+3
|
* Reorganize code to allow path-relative installs.Bruce Momjian2004-05-172-20/+3
| | | | | | | Create new get_* functions to access compiled-in paths and adjust if relative installs are to be used. Clean up substitute_libpath_macro() code.
* More win32 adjustment for timezone directory.Bruce Momjian2004-05-021-3/+2
|
* Fix timezone data path for Unix and win32.Bruce Momjian2004-05-011-3/+5
|
View Lorry Controller Status