timezone should not be explicitly set in postgresql.conf

[lazan]

If timezone is not set, postgresql will use environment variable TZ, which seems, to me, a much better way to alter the timezone from the outside.

[praiskup]

@lazan the timezone within postgersql.conf is set during initdb time, and the 'TZ' environment variable is respected by initdb, at least for me. Can you please confirm?

[praiskup]

Thanks for the report btw, @lazan

[lazan]

@praiskup Ok, perhaps I had the wrong TZ when initialization ran.

But this indicate that there will be an explicit timezone in postgresql.conf, though it'll be the one TZ was during initialization, right?

I want to be able to change the timezone after the initialization in an easy way. Maybe this is by design, and the postgresql way... But to me, using the TZ environment variable is the docker way.

I have a workaround that just sets timezone (taken from TZ) on database level during startup of the container, but it feels "hackish".

[praiskup]

It is unlikely you'll need to change "default" timezone, but if so --then you can simply edit the file by 'docker exec -ti CONTAINER bash' .. or possibly #117.

I have a workaround that just sets timezone (taken from TZ) on database level during startup of the container, but it feels "hackish".

Timezone is session parameter; per-client configuration. Maybe all your clients want to have the same timezone, but this isn't truth in general.

[pkubatrh]

I want to be able to change the timezone after the initialization in an easy way.

I am wondering, what is the use case for this?

[lazan]

It's mostly (only?) for tests in my case.

[lazan]

@praiskup I know how I can change timezone from within the container, my request is to be able to change it from the outside (in a docker way).

The reason is mostly for tests, but also to be symmetric with timezone in containers in general. One could argue the same for timezone in a container/machine/vm, "what is the use case for this".

[lazan]

I'm not trying to be a pain in the butt :) Best case scenario is that I'm wrong and I've learned something.

[praiskup]

(in a docker way)

I'm not sure what this means?

[lazan]

@praiskup To propagate settings/properties via environment variables into a container from the outside, in contrast to entering the container and configure it after it has started from the inside.

[praiskup]

In general, this is a very bad approach; that's because maintainers re-implement perfectly working configuration management (of PostgreSQL). The question is whether we need to re-implement/wrap configuration option 'timezone' in shell, and I don't think it makes sense.

[lazan]

I'm not sure I understand. If timezone is not defined in postgresgl.conf, PostgreSQL will use TZ as the default timezone (on startup). That's what I'm proposing, nothing more, nothing less.

Since the whole timezone semantics is session bound, I don't see why there would be a bad thing to be able to control/affect the default from the outside with the standard timezone environment variable TZ.

I can understand if it's difficult/time consuming to implement, and the benefits is just my use case... I have a workaround, so I'll make do...

[praiskup]

On Monday, December 19, 2016 3:55:45 AM CET lazan wrote:

I'm not sure I understand. If timezone is not defined in postgresgl.conf, PostgreSQL will use TZ as the default timezone (on startup). That's what I'm proposing, nothing more, nothing less.

So you propose to drop 'timezone' option at all, which means we by default (when no TZ is provded) will have GMT. That's behavior change.. Also, are you sure that explicitly setting TZ will help here? It doesn't seem to be the case from quick try.

Also, the '$TZ' variable is too low-level, that affects not only PostgreSQL, and I'm not sure, if any, the variable for PG container should be named like this.

Since the whole timezone semantics is session bound, I don't see why there would be a bad thing to be able to control/affect the default from the outside with the standard timezone environment variable TZ.

That's not a bad thing, the bad thing is that we have a lot of other configuration options in postgresql, which we re-implement in container script just to have longer startups, longer documention and a lot more boring wrapper code (e.g. have a look how we are checking whether db passwords match pre-defined shell regexps, just to pass the password down to database to check that again). But that decision is alrady done ...

... It is always important to decide whether that particular option is worth having wrapped -- and as you said, you use it only for testing; thus I just don't see enough added value here. If there was a nicely formed PR, I wouldn't be strictly against (and I would give you LGTM)... but still I don't see the value.

I can understand if it's difficult/time consuming to implement, and the benefits is just my use case... I have a workaround, so I'll make do...

That's not a work-around. You should pay attention to timezone whenever you connect to random PostgreSQL server in the wild. Or in your case, if you know best the default, set the 'TZ' variable correctly during the initdb time (first container start).

Another point is, as I said the #117 ticket (or other "generic" way to configure server e.g. by providing correctly filled configuration file into 'docker run -v').

[lazan]

So you propose to drop 'timezone' option at all, which means we by default (when no TZ is provded) will have GMT. That's behavior change.. Also, are you sure that explicitly setting TZ will help here? It doesn't seem to be the case from quick try.

Well, the behavior change would only be to db's created after my proposal is implemented. And if I understod you correctly TZ is used in first place to set the explicit default timezone. The point is, if one detects that the db has the wrong default timezone, it would be nice/easy/intuitive to be able to provide an (standard) environment variable TZ during docker run. If you detect this after the first start of the container, your only option is to change the configuration from inside the container (maybe this not the only option).

Yes, if I remove the explicit timezone configuration, PostgreSQL will read the TZ and use it as default timezone, on startup.

Maybe it's my view that the db should dictate the timezone (at least by default) that somewhat contradict PostgreSQL's semantic on session bound timezones. Hence, the default timezone is not really an issue at all...