Ulrich Drepper <drepper@redhat.com> writes:
> If you are misusing interfaces you get what you deserve. At no time was
> it correct to use these functions for general date manipulation. It
> always only was allowed to use them to represent system times and there
> was no Unix system before the epoch. Therefore you argumentation is
> completely wrong.
> If you need date manipulation write your own code which work for all the
> times you want to represent.
We may indeed end up doing that, if glibc fails to provide the
functionality we need; but your argument is nonsense. Unix systems have
*always* interpreted time_t as a signed offset from the epoch. Do you
really think that when Unixen were first built in the early 70s, there
was no interest in working with pre-1970 dates? Hardly likely.
glibc has just taken a large step backwards by comparison to every other
libc on the planet. Claiming that you are okay because you conform to
a lowest-common-denominator ISO spec is beside the point. ISO specs are
only pieces of paper. You have removed functionality that is de facto
standard, important in practice, and *provided by most of your
competition*. People will start going to the competition. Or perhaps
there will be a glibc fork.
Postgres is not the only application that will be complaining loudly
about this change; anyone who has to deal with historical information
is going to be unhappy. We just happen to be the earliest bearers of
the bad news. But you will end up reverting this change due to pushback
from users. Want to make a side bet?
regards, tom lane