[tz] NetBSD vs Darwin timezone API (was: tzdata2016g missing version info)

[Christos Zoulas]

On Nov 10,  6:17pm, tgl at sss.pgh.pa.us (Tom Lane) wrote:
-- Subject: Re: [tz] NetBSD vs Darwin timezone API (was: tzdata2016g missing 

| christos at zoulas.com (Christos Zoulas) writes:
| > I think it is a good idea to have a tzalloc that auto-refreshes the zone
| > file if it has changed. It should fairly straight-forward to implement. I
| > propose to make this the default behavior (tzalloc returns a zone that will
| > auto-update) since most programs would want that
| 
| FWIW, I beg to differ on that.  I know this will break Postgres, which
| is doing pretty much the same thing as Emacs, ie relying on a lot of calls
| to localtime() to infer the system's active timezone.  We only do that
| once during database initialization, so we're not badly exposed, but
| nonetheless this is another data point suggesting that programs in the
| field do have this assumption.
| 
| I think that for backwards compatibility's sake, if nothing else, the
| default behavior should be no auto-update.

This affects only the _z calls. So if you are using tzalloc/*_z
API, this is only when you are going to see this difference. So these
very few programs, can adjust and these are the people who live dangerously
at the forefront of the API; in most cases they will welcome not to have
to change code :-)

| I concur with Paul's suggestion to make it be controlled by a bit in a
| flags word, whichever way the default goes.

Yes, that is fine with me.

| Also ... what will you do for localtime() wherein there's no explicit
| initialization call whereby callers could say which behavior they want?

Nothing happens to that. If you use localtime() you don't get autoupdates.
We could add a new call tzsetflags(int flags); to turn this on for the
statically allocated global timezone... I am not sure if this is a good
idea or not.  I guess Darwin is doing it?

christos
timezones,