While looking at this recent bug report (which still fails in CVS tip)
http://archives.postgresql.org/pgsql-bugs/2003-02/msg00094.php
I realized that the code paths that putatively exist for machines
with neither HAVE_TM_ZONE nor HAVE_INT_TIMEZONE have gone unused
since at least 6.5. Proof is that abstime2tm() doesn't even compile
in that code path (it has a reference to an undefined variable "now").
Since we evidently have no supported platforms that have neither method
of learning the timezone, I propose that we stop contorting the code
with the illusion that we can handle this case reasonably. We can
easily set it up so that we just default to GMT when neither config
symbol is defined.
The reason I want to do this is to remove the dependency on
system-supplied values of CTimeZone and CTZName. CTZName can go
away altogether (ditto CDayLight), and CTimeZone will only be used
when the user explicitly sets a timezone as a numeric offset from
GMT (ie, the HasCTZSet paths). This will save cycles during every
transaction start, where we currently expend time setting these values
(see GetCurrentAbsoluteTimeUsec). And it will fix the above-mentioned
bug, which exists because CTimeZone is set at transaction start and not
updated by a later SET TIMEZONE command.
The bug could be fixed, sort of, by calling GetCurrentAbsoluteTimeUsec
again after executing SET TIMEZONE. But there is a variant scenario
where the same bug exists: if there has been a daylight-savings
transition since the current transaction started, we'll still get the
wrong answers. So trying to make CTimeZone track the current timezone
correctly seems doomed to failure anyhow.
Any objections?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: 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
