Re: pgsql-server/src/backend/utils/adt datetime.c
От | Tom Lane |
---|---|
Тема | Re: pgsql-server/src/backend/utils/adt datetime.c |
Дата | |
Msg-id | 17875.1031087559@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql-server/src/backend/utils/adt datetime.c (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-committers |
Bruce Momjian <pgman@candle.pha.pa.us> writes: > Tom, is there some standard they can point to to break localtime() too? I dunno. Logically, if mktime cannot validly output a negative time_t, then a negative input to localtime isn't valid either. However, there is no defined "failure" return from localtime, so it would not be easy to simply arbitrarily refuse the input value. What is more likely to happen is that at some point localtime will start interpreting its input as an unsigned offset from 1970, so that what we think is a time in 1969 will come out as a time in 2039 or so. We really want to be out from under the C-library timezone API before then ... the silly thing is that the amount of cruft that exists in the timezone code to cope with Unix-compatible APIs is probably comparable to the amount of extra functionality we'd need to write to avoid depending on the C library's time routines. We already do most of our own time arithmetic --- we are essentially *only* depending on the C library to answer the question "what timezone is this local time in", ie "what are the DST rules"? regards, tom lane
В списке pgsql-committers по дате отправления: