|
1 | 1 | src/timezone/README
|
2 | 2 |
|
3 |
| -Timezone |
4 |
| -======== |
| 3 | +This is a PostgreSQL adapted version of the IANA timezone library from |
5 | 4 |
|
6 |
| -This is a PostgreSQL adapted version of the timezone library from |
7 |
| -http://www.iana.org/time-zones |
| 5 | + http://www.iana.org/time-zones |
8 | 6 |
|
9 |
| -The source code can be found at: |
| 7 | +The latest versions of both the tzdata and tzcode tarballs are normally |
| 8 | +available right from that page. Historical versions can be found |
| 9 | +elsewhere on the site. |
10 | 10 |
|
11 |
| - ftp://ftp.iana.org/tz/releases/tzcode*.tar.gz |
12 |
| - |
13 |
| -The code is currently synced with release 2010c. There are many cosmetic |
14 |
| -(and not so cosmetic) differences from the original tzcode library, but |
15 |
| -diffs in the upstream version should usually be propagated to our version. |
| 11 | +Since time zone rules change frequently in some parts of the world, |
| 12 | +we should endeavor to update the data files before each PostgreSQL |
| 13 | +release. The code need not be updated as often, but we must track |
| 14 | +changes that might affect interpretation of the data files. |
16 | 15 |
|
17 |
| -The data files under data/ are an exact copy of the latest data set from: |
18 | 16 |
|
19 |
| - ftp://ftp.iana.org/tz/releases/tzdata*.tar.gz |
| 17 | +Time Zone data |
| 18 | +============== |
20 | 19 |
|
21 |
| -Since time zone rules change frequently in some parts of the world, |
22 |
| -we should endeavor to update the data files before each PostgreSQL |
23 |
| -release. |
| 20 | +The data files under data/ are an exact copy of the latest tzdata set, |
| 21 | +except that we omit some files that are not of interest for our purposes. |
24 | 22 |
|
25 |
| -At each update, we should check if time zone offsets have changed. |
26 |
| -Just search for the current or previous year and see what has changed. |
27 |
| -Sometimes a country changes its time zone offsets, for example Georgia |
28 |
| -in 2004. Just grepping in the zic database files for 2004 is enough to |
29 |
| -spot such a change. Then the files under tznames/ should be updated. |
| 23 | +While the files under data/ can just be duplicated when updating, manual |
| 24 | +effort is needed to update the time zone abbreviation lists under tznames/. |
| 25 | +These need to be changed whenever new abbreviations are invented or the |
| 26 | +UTC offset associated with an existing abbreviation changes. To detect |
| 27 | +if this has happened, after installing new files under data/ do |
| 28 | + make abbrevs.txt |
| 29 | +which will produce a file showing all abbreviations that are in current |
| 30 | +use according to the data/ files. Compare this to known_abbrevs.txt, |
| 31 | +which is the list that existed last time the tznames/ files were updated. |
| 32 | +Update tznames/ as seems appropriate, then replace known_abbrevs.txt |
| 33 | +in the same commit. Usually, if a known abbreviation has changed meaning, |
| 34 | +the appropriate fix is to make it refer to a long-form zone name instead |
| 35 | +of a fixed GMT offset. |
30 | 36 |
|
31 | 37 | When there has been a new release of Windows (probably including Service
|
32 | 38 | Packs), the list of matching timezones need to be updated. Run the
|
33 | 39 | script in src/tools/win32tzlist.pl on a Windows machine running this new
|
34 | 40 | release and apply any new timezones that it detects. Never remove any
|
35 | 41 | mappings in case they are removed in Windows, since we still need to
|
36 | 42 | match properly on the old version.
|
| 43 | + |
| 44 | + |
| 45 | +Time Zone code |
| 46 | +============== |
| 47 | + |
| 48 | +The code in this directory is currently synced with tzcode release 2016c. |
| 49 | +There are many cosmetic (and not so cosmetic) differences from the |
| 50 | +original tzcode library, but diffs in the upstream version should usually |
| 51 | +be propagated to our version. Here are some notes about that. |
| 52 | + |
| 53 | +For the most part we want to use the upstream code as-is, but there are |
| 54 | +several considerations preventing an exact match: |
| 55 | + |
| 56 | +* For readability/maintainability we reformat the code to match our own |
| 57 | +conventions; this includes pgindent'ing it and getting rid of upstream's |
| 58 | +overuse of "register" declarations. (It used to include conversion of |
| 59 | +old-style function declarations to C89 style, but thank goodness they |
| 60 | +fixed that.) |
| 61 | + |
| 62 | +* We need the code to follow Postgres' portability conventions; this |
| 63 | +includes relying on configure's results rather than hand-hacked #defines, |
| 64 | +and not relying on <stdint.h> features that may not exist on old systems. |
| 65 | +(In particular this means using Postgres' definitions of the int32 and |
| 66 | +int64 typedefs, not int_fast32_t/int_fast64_t.) |
| 67 | + |
| 68 | +* Since Postgres is typically built on a system that has its own copy |
| 69 | +of the <time.h> functions, we must avoid conflicting with those. This |
| 70 | +mandates renaming typedef time_t to pg_time_t, and similarly for most |
| 71 | +other exposed names. |
| 72 | + |
| 73 | +* We have exposed the tzload() and tzparse() internal functions, and |
| 74 | +slightly modified the API of the former, in part because it now relies |
| 75 | +on our own pg_open_tzfile() rather than opening files for itself. |
| 76 | + |
| 77 | +* There's a fair amount of code we don't need and have removed, |
| 78 | +including all the nonstandard optional APIs. We have also added |
| 79 | +a few functions of our own at the bottom of localtime.c. |
| 80 | + |
| 81 | +* In zic.c, we have added support for a -P (print_abbrevs) switch, which |
| 82 | +is used to create the "abbrevs.txt" summary of currently-in-use zone |
| 83 | +abbreviations that was described above. |
| 84 | + |
| 85 | + |
| 86 | +The most convenient way to compare a new tzcode release to our code is |
| 87 | +to first run the tzcode source files through a sed filter like this: |
| 88 | + |
| 89 | + sed -r \ |
| 90 | + -e 's/^([ \t]*)\*\*([ \t])/\1 *\2/' \ |
| 91 | + -e 's/^([ \t]*)\*\*$/\1 */' \ |
| 92 | + -e 's|^\*/| */|' \ |
| 93 | + -e 's/\bregister[ \t]//g' \ |
| 94 | + -e 's/int_fast32_t/int32/g' \ |
| 95 | + -e 's/int_fast64_t/int64/g' \ |
| 96 | + -e 's/struct[ \t]+tm\b/struct pg_tm/g' \ |
| 97 | + -e 's/\btime_t\b/pg_time_t/g' \ |
| 98 | + |
| 99 | +and then run them through pgindent. (The first three sed patterns deal |
| 100 | +with conversion of their block comment style to something pgindent |
| 101 | +won't make a hash of; the remainder address other points noted above.) |
| 102 | +After that, the files can be diff'd directly against our corresponding |
| 103 | +files. |
0 commit comments