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

Guy Harris guy at alum.mit.edu
Fri Nov 11 04:23:58 UTC 2016


On Nov 10, 2016, at 7:52 PM, Tom Lane <tgl at sss.pgh.pa.us> wrote:

> Guy Harris <guy at alum.mit.edu> writes:
>> On Nov 10, 2016, at 3:17 PM, Tom Lane <tgl at sss.pgh.pa.us> wrote:
>>> 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.
> 
>> Why does Postgres need to know the system's active time zone?
> 
> To select a reasonable default for the "timezone" setting.

OK, it says here:

	https://www.postgresql.org/docs/current/static/datatype-datetime.html#DATATYPE-TIMEZONES

"PostgreSQL allows you to specify time zones in three different forms:

	* A full time zone name, for example America/New_York. The recognized time zone names are listed in the pg_timezone_names view (see Section 50.80). PostgreSQL uses the widely-used IANA time zone data for this purpose, so the same time zone names are also recognized by much other software.

	* A time zone abbreviation, for example PST. Such a specification merely defines a particular offset from UTC, in contrast to full time zone names which can imply a set of daylight savings transition-date rules as well. The recognized abbreviations are listed in the pg_timezone_abbrevs view (see Section 50.79). You cannot set the configuration parameters TimeZone or log_timezone to a time zone abbreviation, but you can use abbreviations in date/time input values and with the AT TIME ZONE operator.

	* In addition to the timezone names and abbreviations, PostgreSQL will accept POSIX-style time zone specifications of the form STDoffset or STDoffsetDST, where STD is a zone abbreviation, offset is a numeric offset in hours west from UTC, and DST is an optional daylight-savings zone abbreviation, assumed to stand for one hour ahead of the given offset. For example, if EST5EDT were not already a recognized zone name, it would be accepted and would be functionally equivalent to United States East Coast time. In this syntax, a zone abbreviation can be a string of letters, or an arbitrary string surrounded by angle brackets (<>). When a daylight-savings zone abbreviation is present, it is assumed to be used according to the same daylight-savings transition rules used in the IANA time zone database's posixrules entry. In a standard PostgreSQLinstallation, posixrules is the same as US/Eastern, so that POSIX-style time zone specifications follow USA daylight-savings rules. If needed, you can adjust this behavior by replacing the posixrules file."

If that's the time zone setting you're referring to, the first and third of those sounds like standard TZ settings.

So what are the localtime() calls doing?  Is this an attempt to guess, if the TZ environment variable isn't set, to guess which of the tzdb zones are in effect on the system?  Or is it an attempt to determine the tzdb zone on systems that *don't* use the tzdb for UTC-to-local-time mappings (Windows, HP-UX?, etc.)?  Or is it an attempt to deal with the "time zone abbreviation" case?

Note also that, as I indicated, on a Mac, the system time zone setting is not guaranteed to remain the same during the lifetime of a process.  I don't know what *other* systems that have a "where in the world am I" OS service do in that regard, but at least some of them might support the same thing Darwin does.

>> This bounced with "Diagnostic-Code: SMTP; 551 5.7.1 Rejected due to SPF
>> mismatch" when Tom was CCed, perhaps because my From: address's domain
>> name isn't the same as my mail server's domain name, or
> 
> Sorry about that ... experimental spam filtering.

Still bouncing.

> But you should think
> twice about sending email claiming to be from an MIT address out of
> servers that are not MIT's.  It's a good way to get blocked, and to
> get your mail provider's servers blocked too.

What alternative to the MIT Alumni Association's email forwarding service would you suggest to allow me to use an email address independent of my email current service provider (and that would allow me to, if necessary, forward email to that address to more than one other email address, which I've done in the past)?  I'm not doing that just for the lulz.


More information about the tz mailing list