Re: time_t timezone

Tom Lane schrieb:
> Reini Urban <rurban(at)x-ray(dot)at> writes:
>
>>But the time_t timezone issue is here:
>> "XSHd7 Aardvark Change Request Report"
>> http://www.opengroup.org/austin/docs/austin_97.txt
>>(ERN 20 Accept as marked, page 1177)
>
> There is nothing whatever on that page about the datatype of the
> timezone variable.

"1) in POSIX, the time_t value is always related to local time by
the "seconds since the Epoch" expression and the timezone
information."

Yes, they are talking about the localtime return value,
but nevertheless the newlib folks refer to that. Their fault.

Should I discuss that with them? I will not do that.
newlib is happening in the real world, standards just a general
consensus, how it should happen.
If some other platforms use newlib, you are lost with the make abort.

>>Caldera, redhat and IRIX 6.2 at least use time_t
>> http://uw713doc.sco.com/en/man/html.3C/ctime.3C.html
>
> Red Hat certainly does not:
>
> [tgl(at)rh1 include]$ grep timezone /usr/include/*h
> /usr/include/time.h: of *TIMER in the local timezone. */
> /usr/include/time.h:extern char *__tzname[2]; /* Current timezone names. */
> /usr/include/time.h:extern long int __timezone; /* Seconds west of UTC. */
> /usr/include/time.h:extern long int timezone;
> [tgl(at)rh1 include]$

dertainly depends which redhat. I have no redhat around and newlib is
quite new. This pgtz timezone code is also quite new.

> But what may be more to the point is that AFAICS we make no assumption
> about the exact datatype of the timezone variable. So long as it is
> some signed integer type (which surely it must be), the code will work.
> I see no reason to add a configure test to test something we do not care
> about.

Bruce' patch only assumes time_t on CYGWIN and it is only for pgtypeslib
(src/interfaces/ecpg/pgtypeslib/dt.h). Not for src/timezone/pgtz.c

Fact is: src/timezone/pgtz.c does not compile on cygwin,
and will not compile on any other similar platform, as I saw from
googling around, unless it is checked in configure.in or
- the dirty way - casted away in src/timezone/pgtz.c and the .m4 macro.

Since the current configure check does not define HAVE_INT_TIMEZONE (not
casted there, so it fails), the whole pgtz #ifdef branch will abort.

http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/timezone/pgtz.c?rev=HEAD;content-type=text%2Fx-cvsweb-markup
and
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/config/c-library.m4?rev=HEAD;content-type=text%2Fx-cvsweb-markup
are wrong without the cast.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/