Ulrich Drepper <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster