Thread: Timezone: resolve $TZDIR in runtime
Hello,
I was recently working with a project which embeds postgres into application. It uses binaries built for Debian, and configured to look for timezones in Debian's timezone folder /usr/share/zoneinfo/, which wasn't present on my system.
I was thinking if it's possible to redefine it in runtime, and found that it is not possible: postgres support either compilation flag --with-system-tzdata or built-in tz file -- timezone/data/tzdata.zi. From the other hand, looking at src/timezone/pgtz.c#L54, it seems that timezone dir resolve happens in runtime, which means, it is possible to use $TZDIR environment variable or configuration option to achieve this without recompilation.
Do you think it is a feasible thing to do? it would be very convenient for portable postgers builds.
Thanks!
Anatolii Smolianinov <zarkonesmall@gmail.com> writes:
> I was recently working with a project which embeds postgres into
> application. It uses binaries built for Debian, and configured to look for
> timezones in Debian's timezone folder /usr/share/zoneinfo/, which wasn't
> present on my system.
Why are you trying to use binaries built for Debian on some other
platform? Seems like there'd be more problems than just timezones.
> I was thinking if it's possible to redefine it in runtime, and found that
> it is not possible: postgres support either compilation flag
> --with-system-tzdata or built-in tz file -- timezone/data/tzdata.zi. From
> the other hand, looking at src/timezone/pgtz.c#L54, it seems that timezone
> dir resolve happens in runtime, which means, it is possible to use $TZDIR
> environment variable or configuration option to achieve this without
> recompilation.
I'm pretty down on this idea because it adds complexity, ie ways to
break things. If you want a more self-contained installation, you
could build it without specifying --with-system-tzdata.
regards, tom lane
Hi Tom, thanks for your reply!
I understand your point, and also, the idea of embedding postgresql -- it might be just not what postgresql is built for. I was just thinking that respecting the standard TZDIR approach would add more flexibility.
If you have 5 linux distros and everyone has a different tzdata location, it doesn't make much sense to rebuild binaries for each of these distros. Which means, compile time config is actually the part which adds complexity -- at least for packaging.
There is no point in having $TZDIR if it's not respected by software. Also, it feels that setting the filesystem path in compile time just doesn't make much sense -- it should be a part of runtime configuration.
In my case though, it doesn't block me or anything, -- as you've mentioned, I can just rebuild without this flag. I was just thinking that supporting the standard way of timezone configuration would improve the experience of using postgresql in general and make it more predictive. Maybe it's not true though due to legacy reasons though -- old users just wouldn't expect $TZDIR to alter the configuration.
On Mon, Oct 21, 2024 at 4:37 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Anatolii Smolianinov <zarkonesmall@gmail.com> writes:
> I was recently working with a project which embeds postgres into
> application. It uses binaries built for Debian, and configured to look for
> timezones in Debian's timezone folder /usr/share/zoneinfo/, which wasn't
> present on my system.
Why are you trying to use binaries built for Debian on some other
platform? Seems like there'd be more problems than just timezones.
> I was thinking if it's possible to redefine it in runtime, and found that
> it is not possible: postgres support either compilation flag
> --with-system-tzdata or built-in tz file -- timezone/data/tzdata.zi. From
> the other hand, looking at src/timezone/pgtz.c#L54, it seems that timezone
> dir resolve happens in runtime, which means, it is possible to use $TZDIR
> environment variable or configuration option to achieve this without
> recompilation.
I'm pretty down on this idea because it adds complexity, ie ways to
break things. If you want a more self-contained installation, you
could build it without specifying --with-system-tzdata.
regards, tom lane
On 10/21/24 08:03, Anatolii Smolianinov wrote: > Hi Tom, thanks for your reply! > > I understand your point, and also, the idea of embedding postgresql -- > it might be just not what postgresql is built for. I was just thinking > that respecting the standard TZDIR approach would add more flexibility. https://wiki.postgresql.org/wiki/Not_Worth_Doing#Features_We_Do_Not_Want "Embedded server While PostgreSQL clients runs fine in limited-resource environments, the server requires multiple processes and a stable pool of resources to run reliably and efficiently. Stripping down the PostgreSQL server to run in the same process address space as the client application would add too much complexity and failure cases. Besides, there are several very mature embedded SQL databases already available. " -- Adrian Klaver adrian.klaver@aklaver.com
Hi Adrian!
Totally agree.
I think embedded postgresql appeared mainly because of compatibility reasons. If you are using postgres on server, with some of the custom features which you can't find in other databases, and want to enable "local mod" for your users, (and also for tests maybe), but you don't want to roll out a compatibility layer with e.g. sqlite.
As I've mentioned, it's not about embedded really, it is more about support of standard $TZDIR mechanics in general. Embedded postgresql was mentioned just for the context of my use case.
On Mon, Oct 21, 2024 at 5:53 PM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
On 10/21/24 08:03, Anatolii Smolianinov wrote:
> Hi Tom, thanks for your reply!
>
> I understand your point, and also, the idea of embedding postgresql --
> it might be just not what postgresql is built for. I was just thinking
> that respecting the standard TZDIR approach would add more flexibility.
https://wiki.postgresql.org/wiki/Not_Worth_Doing#Features_We_Do_Not_Want
"Embedded server
While PostgreSQL clients runs fine in limited-resource
environments, the server requires multiple processes and a stable pool
of resources to run reliably and efficiently. Stripping down the
PostgreSQL server to run in the same process address space as the client
application would add too much complexity and failure cases. Besides,
there are several very mature embedded SQL databases already available. "
--
Adrian Klaver
adrian.klaver@aklaver.com
Anatolii Smolianinov <zarkonesmall@gmail.com> writes:
> As I've mentioned, it's not about embedded really, it is more about support
> of standard $TZDIR mechanics in general.
One problem with your argument is that there's no standard mentioning
TZDIR, nor does it appear to affect actually-standard utilities
like date(1).
regards, tom lane
Right, it is not an official standard, but TZDIR appears in tzselect, which comes from GNU libc. https://www.unix.com/man-page/redhat/8/TZSELECT/
date(1) does not set timezone dir: but it uses TZ, and, in man, it refers to tzselect:
> use tzselect to find TZ"
On Mon, Oct 21, 2024 at 6:16 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Anatolii Smolianinov <zarkonesmall@gmail.com> writes:
> As I've mentioned, it's not about embedded really, it is more about support
> of standard $TZDIR mechanics in general.
One problem with your argument is that there's no standard mentioning
TZDIR, nor does it appear to affect actually-standard utilities
like date(1).
regards, tom lane
On 2024-10-21 Anatolii Smolianinov <zarkonesmall@gmail.com> wrote:
> date(1) does not set timezone dir: but it uses TZ, and, in man, it
> refers to tzselect:
> > use tzselect to find TZ"
That's an imperative "use", not an indicative. In other words: the
user, to find an appropriate value for `TZ`, should run the command
`tzselect`.
--
Dakkar - <Mobilis in mobile>
GPG public key fingerprint = A071 E618 DD2C 5901 9574
6FE2 40EA 9883 7519 3F88
key id = 0x75193F88
Anatolii Smolianinov <zarkonesmall@gmail.com> writes: > Right, it is not an official standard, but TZDIR appears in tzselect, which > comes from GNU libc. https://www.unix.com/man-page/redhat/8/TZSELECT/ No, it comes from the tzdb distribution, which otherwise hard-wires a compile-time choice for that directory. Which is how come no other program responds to that environment variable. So if anything, that's precedent for our behavior. regards, tom lane
Ah, I see -- so tzselect uses tzdb distribution too? it is just, tzselect can alter the timezone database and it looks for TZDIR in some distributions, however, it is not the source of truth in that sense. I think I see now why it's not really feasible to make such an adjustment..
Thanks for your help!
On Mon, Oct 21, 2024 at 7:59 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Anatolii Smolianinov <zarkonesmall@gmail.com> writes:
> Right, it is not an official standard, but TZDIR appears in tzselect, which
> comes from GNU libc. https://www.unix.com/man-page/redhat/8/TZSELECT/
No, it comes from the tzdb distribution, which otherwise hard-wires
a compile-time choice for that directory. Which is how come no other
program responds to that environment variable. So if anything, that's
precedent for our behavior.
regards, tom lane