Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4
Tom Lane wrote: Josh Berkus josh@agliodbs.com writes: Zdenec, I have following idea: 1) add guc varibale which enable usage of OS time zone files 2) add extra parameters into ./configure script which enable OS TZ support in the code and get path to OS TZ files. If we're adding it as a configure-time variable, there's no reason to have a GUC. I see zero reason to have either. It would only make sense to do this in the context of a platform-specific distribution such as an RPM, and in that context the simplest solution is to let the RPM specfile make the substitution (ie, after make install and before packaging, rm -rf PG's timezone tree and insert a symlink). Then it's on the RPM packager's head whether it's the right thing to do or not. A configure switch strikes me as mostly a foot-gun, because the average user of Postgres won't have any way to know whether the files are compatible. I don't think to make a symlink is good solution. It generates a lot of future problem with package update or patching. Configure switch is much comfortable for packagers/patch makers. In case when average user want to compile own postgres we can offer regression test focused on TZ validation. (By the way average user is surprise, that postgres has own zone files) I also think, usage system's timezone files should be by default and configure script determines zonefiles location based on OS. Another location could be set by switch. If for some platform will be necessary use own copy, special switch (e.g. --enable-internal-tzfiles) setup postgres for process own timezone copy. Zdenek PS: For information there are TZ locations on several OS: /usr/share/lib/zoneinfo Solaris /usr/share/zoneinfo Redhat /opt/dce/lib/zoneinfo HP-UX (no TZif magic word) /etc/zoneinfo/ Tru64 (no TZif magic word) /usr/share/zoneinfo/MacOS registers MS Windows ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4
Granted, but a configure switch would allow users who want to use OS TZ file in conjunction with a compiled from source installation. Many users of OSes with package managers such as Debian or RedHat may, for whatever reason, want to use a source tarball to install and also use the OS TZ list. That being said, this user group may be small enough to ignore. Just throwing it in for thought. Tom Lane wrote: Josh Berkus josh@agliodbs.com writes: Zdenec, I have following idea: 1) add guc varibale which enable usage of OS time zone files 2) add extra parameters into ./configure script which enable OS TZ support in the code and get path to OS TZ files. If we're adding it as a configure-time variable, there's no reason to have a GUC. I see zero reason to have either. It would only make sense to do this in the context of a platform-specific distribution such as an RPM, and in that context the simplest solution is to let the RPM specfile make the substitution (ie, after "make install" and before packaging, rm -rf PG's timezone tree and insert a symlink). Then it's on the RPM packager's head whether it's the right thing to do or not. A configure switch strikes me as mostly a foot-gun, because the average user of Postgres won't have any way to know whether the files are compatible. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4
On Wed, Mar 14, 2007 at 01:13:58PM +0100, Zdenek Kotala wrote: I don't think to make a symlink is good solution. It generates a lot of future problem with package update or patching. Configure switch is much comfortable for packagers/patch makers. In case when average user want to compile own postgres we can offer regression test focused on TZ validation. (By the way average user is surprise, that postgres has own zone files) What is the actual problem being solved here? That people expected the timezone changes to be picked up automatically? think if you weigh it up, that problem is less significant than: 1. You do a minor system upgrade and now postgres crashes because the file format changed or the files moved. 2. You run a replication system and get different results on different machine. I think that from a data integrity point of view the current system is the best. At the very least what you propose is a modularity violation: Postgres depending on undocumented private data of another system component. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4
Martijn van Oosterhout wrote: I think that from a data integrity point of view the current system is the best. At the very least what you propose is a modularity violation: Postgres depending on undocumented private data of another system component. I don't think you can reasonably describe the system timezone database as undocumented private data. Plenty of other systems rely on it, as we used to do. But I take Tom's point about most users not knowing if their TZ database is usable or not. Maybe we need a tool (maybe on pgfoundry) that will do some analysis to find out, if such a thing is possible. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4
Martijn van Oosterhout wrote: On Wed, Mar 14, 2007 at 01:13:58PM +0100, Zdenek Kotala wrote: I don't think to make a symlink is good solution. It generates a lot of future problem with package update or patching. Configure switch is much comfortable for packagers/patch makers. In case when average user want to compile own postgres we can offer regression test focused on TZ validation. (By the way average user is surprise, that postgres has own zone files) What is the actual problem being solved here? That people expected the timezone changes to be picked up automatically? think if you weigh it up, that problem is less significant than: People expect consistent timezone setting for all application on one machine. 1. You do a minor system upgrade and now postgres crashes because the file format changed or the files moved. When you perform minor system upgrade which will delivery new TZ file format, than new version of libc must be delivery anyway and you probably must recompile postgres on upgraded system - you can check if TZ files works fine and if not you can compile it with build in. If file is moved, postgres raises error. But I don't see problem there. If you compare changes between 8.1.5 and 8.1.6, you can see a lot of removed files. 2. You run a replication system and get different results on different machine. However on another point of view, You very often have application and postgres on one machine. And if you have different tz files for application and for postgres, the result should be really strange. This case is most common than replication issue. I think that from a data integrity point of view the current system is the best. At the very least what you propose is a modularity violation: Postgres depending on undocumented private data of another system component. Yes, it is true, dependency on private data is not good. But It is smaller evil, than have more different timezone on one system. Zdenek ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4
Andrew Dunstan wrote: Martijn van Oosterhout wrote: I think that from a data integrity point of view the current system is the best. At the very least what you propose is a modularity violation: Postgres depending on undocumented private data of another system component. I don't think you can reasonably describe the system timezone database as undocumented private data. Plenty of other systems rely on it, as we used to do. But I take Tom's point about most users not knowing if their TZ database is usable or not. Maybe we need a tool (maybe on pgfoundry) that will do some analysis to find out, if such a thing is possible. I guess some regression test should test TZ validity? Zdenek ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4
Andrew Dunstan wrote: Martijn van Oosterhout wrote: I think that from a data integrity point of view the current system is the best. At the very least what you propose is a modularity violation: Postgres depending on undocumented private data of another system component. I don't think you can reasonably describe the system timezone database as undocumented private data. Plenty of other systems rely on it, as we used to do. No -- we relied on the libc's TZ API, which is not the same. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4
Martijn van Oosterhout kleptog@svana.org writes: What is the actual problem being solved here? That people expected the timezone changes to be picked up automatically? think if you weigh it up, that problem is less significant than: ... One other point is that symlinking to system timezone info will not cause Postgres to pick up changes automatically. You'll probably still need a postmaster restart to get the new settings loaded in. If the timezone info update is delivered as part of a Postgres update, the need for this is fairly obvious, but if it's happening as part of an update of a seemingly unrelated package, not so much. To me, the idea of linking to system timezone info is a convenience for packagers, and it is (and should be) the packagers' responsibility to determine whether it's a sane idea for their environment. If they are competent to determine that, they are certainly competent enough to make it happen without assistance from our configure script. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4
Andrew Dunstan [EMAIL PROTECTED] writes: But I take Tom's point about most users not knowing if their TZ database is usable or not. Maybe we need a tool (maybe on pgfoundry) that will do some analysis to find out, if such a thing is possible. It's not really *that* hard: diff between our timezone files and the system files will make it pretty clear. For instance, diffing a CVS HEAD installation against a not-too-up-to-date Fedora Core 5 system shows only a few different files, reflecting the fact that they're different snapshots of the zic database: $ diff -r --br . /usr/share/zoneinfo Files ./America/Havana and /usr/share/zoneinfo/America/Havana differ Files ./America/Santiago and /usr/share/zoneinfo/America/Santiago differ Files ./Antarctica/Palmer and /usr/share/zoneinfo/Antarctica/Palmer differ Files ./Australia/Perth and /usr/share/zoneinfo/Australia/Perth differ Files ./Australia/West and /usr/share/zoneinfo/Australia/West differ Files ./Chile/Continental and /usr/share/zoneinfo/Chile/Continental differ Files ./Chile/EasterIsland and /usr/share/zoneinfo/Chile/EasterIsland differ Files ./Cuba and /usr/share/zoneinfo/Cuba differ Files ./Pacific/Easter and /usr/share/zoneinfo/Pacific/Easter differ Only in ./US: Pacific-New Only in /usr/share/zoneinfo: iso3166.tab Only in /usr/share/zoneinfo: posix Only in /usr/share/zoneinfo: posixrules Only in /usr/share/zoneinfo: right Only in /usr/share/zoneinfo: zone.tab $ But IMHO the thing that you need to know to make an informed decision is what the future update path for that system is likely to be. In the case of me packaging Postgres for Red Hat, I feel pretty comfortable that there will be no major surgery on glibc's timezone code within any single RHEL release series, so if it works today it'll still work tomorrow. A Sun engineer packaging Postgres for Solaris may be able to make the same kind of determination. But I think Joe Average User is sticking his neck out if he assumes such a thing for say a Gentoo box ... regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Daylight Saving Time question PostgreSQL 8.1.4
It appears that we didn't do enough research in regards to the recent DST switch. We poorly assumed that having our machine's timezone files up to date would be sufficient not knowing that our version of postgres relied on its own timezone files. The question is... can we symlink the share/postgresql/timezone/ directory to our OS X /usr/share/zoneinfo to without fear of breaking anything in the future? I'm also curious about the rationale to maintain a separate timezone data files for machines that supply them. Sincerely, Michael ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4
Michael, I'm also curious about the rationale to maintain a separate timezone data files for machines that supply them. It's because we found that we couldn't ensure consistency between operating systems while relying on OS files. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4
Tom, You can try the symlink game if you want, but it'll be on your own head whether it works or not. (For the record, I am hoping to do exactly that in future releases for Red Hat ... but in that context I know what the system's timezone code is. I'm less sure that I know what Apple is using.) Yeah, Solaris wants us to do the same thing ... use their files. At some point, I'll have to hack it and see how it works. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4
You can try the symlink game if you want, but it'll be on your own head whether it works or not. (For the record, I am hoping to do exactly that in future releases for Red Hat ... but in that context I know what the system's timezone code is. I'm less sure that I know what Apple is using.) Thank you all for your speedy and informative replies. I had a good idea why you wouldn't symlink (for release consistency), but I wasn't aware that there were format differences in the timezone files. Currently Apple's format appears to work fine with postgresql. And given the responses and to make a quick job of it I will be copying Apple's files only on the machines affected instead of symlinking until we can coordinate a new version update. It seems that we are only being affected in Canada... Thanks again, Michael ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4
Michael, Currently Apple's format appears to work fine with postgresql. And given the responses and to make a quick job of it I will be copying Apple's files only on the machines affected instead of symlinking until we can coordinate a new version update. It seems that we are only being affected in Canada... Canada and AU changed their DST rules with 4 months notice. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4
Tom Lane wrote: Josh Berkus josh@agliodbs.com writes: Michael, I'm also curious about the rationale to maintain a separate timezone data files for machines that supply them. It's because we found that we couldn't ensure consistency between operating systems while relying on OS files. Partly that, and partly that we needed operations that the standard C library doesn't supply. Hence we had to have direct access to the timezone database, and since different systems have different representations of timezone data, we couldn't really rely on the system's data. You can try the symlink game if you want, but it'll be on your own head whether it works or not. (For the record, I am hoping to do exactly that in future releases for Red Hat ... but in that context I know what the system's timezone code is. I'm less sure that I know what Apple is using.) I have following idea: 1) add guc varibale which enable usage of OS time zone files 2) add extra parameters into ./configure script which enable OS TZ support in the code and get path to OS TZ files. It probably will require some OS specific code for reading and translation TZ file format. What do you mean about it? Thanks Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4
Zdenec, I have following idea: 1) add guc varibale which enable usage of OS time zone files 2) add extra parameters into ./configure script which enable OS TZ support in the code and get path to OS TZ files. If we're adding it as a configure-time variable, there's no reason to have a GUC. It probably will require some OS specific code for reading and translation TZ file format. This would require each OS to make a committment to support their compatibility code. Like, we would have to maintain the Solaris code, if any was required. Ideally, no glue code would be required. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4
Josh Berkus wrote: Tom, You can try the symlink game if you want, but it'll be on your own head whether it works or not. (For the record, I am hoping to do exactly that in future releases for Red Hat ... but in that context I know what the system's timezone code is. I'm less sure that I know what Apple is using.) Yeah, Solaris wants us to do the same thing ... use their files. At some point, I'll have to hack it and see how it works. perhaps we should have a configure flag like --with-timezone-base=/usr/share/zoneinfo cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4
Josh Berkus josh@agliodbs.com writes: Zdenec, I have following idea: 1) add guc varibale which enable usage of OS time zone files 2) add extra parameters into ./configure script which enable OS TZ support in the code and get path to OS TZ files. If we're adding it as a configure-time variable, there's no reason to have a GUC. I see zero reason to have either. It would only make sense to do this in the context of a platform-specific distribution such as an RPM, and in that context the simplest solution is to let the RPM specfile make the substitution (ie, after make install and before packaging, rm -rf PG's timezone tree and insert a symlink). Then it's on the RPM packager's head whether it's the right thing to do or not. A configure switch strikes me as mostly a foot-gun, because the average user of Postgres won't have any way to know whether the files are compatible. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Daylight saving time
Dear Dennis and my Fellowmen, How would you like to evaluate a new simplified time zone system for the world and in decimal? This is found in http://www.geocities.com/peacecrusader888/timezone.htm. Best regards, Aristeo Canlas Fernando, Peace Crusader, ICD Motto: pro aris et focis http://www,geocities.com/peacecrusader888/ [EMAIL PROTECTED] (Dennis Bjorklund) wrote in message news:[EMAIL PROTECTED]... I found a nice page about daylight saving time that I want to share: http://timeanddate.com/time/aboutdst.html Here are some fun quotes from the page: Sometimes DST is used for longer periods than just one summer, as in the United States during World War II. From 3 Feb 1942 to 30 Sep 1945 most of United States had DST all year, it was called War Time. many countries change the transition days/principles every year because of special happenings or conditions that has happened or will happen. Also notice the current list of DST changes for this fall 2004: http://timeanddate.com/time/dst2004b.html I can understand why they did not try to formalize that in the sql spec. ps. This letter does not mean that I think it's bad to handle time zone names, just that it's even more difficult then I first thought. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Daylight saving time
I found a nice page about daylight saving time that I want to share: http://timeanddate.com/time/aboutdst.html Here are some fun quotes from the page: Sometimes DST is used for longer periods than just one summer, as in the United States during World War II. From 3 Feb 1942 to 30 Sep 1945 most of United States had DST all year, it was called War Time. many countries change the transition days/principles every year because of special happenings or conditions that has happened or will happen. Also notice the current list of DST changes for this fall 2004: http://timeanddate.com/time/dst2004b.html I can understand why they did not try to formalize that in the sql spec. ps. This letter does not mean that I think it's bad to handle time zone names, just that it's even more difficult then I first thought. -- /Dennis Björklund ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Daylight saving time
Dennis Bjorklund [EMAIL PROTECTED] writes: ps. This letter does not mean that I think it's bad to handle time zone names, just that it's even more difficult then I first thought. This is why we are being careful not to introduce any local changes into the zic database. We can just drop in upstream changes from time to time; or users can drop in copies if they need an update and it's the wrong time of the PG release cycle. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
