> it seems that the year handling in pgsql dates is not very consistent:
> The problem I see is that the same number is converted to a different
> year depending on the number of digits and the number itself. I think
> that this kind of things are the most likely sources of Y2K troubles.
> A more consistent approach would be to treat the year literally and
> let any smart hack with dates entirely to the user under his
> responsability.
I agree that there are some cases in your examples which should be
giving a different result. Not *every* example you gave led to an
incorrect or unpredictable result, so could you please identify those
you feel are a problem? In glancing at the examples, the ones with zero
value (but lots of zeros) seem to be a problem, and perhaps some or all
of the ones with an odd number of year digits. Any others?
We do need to handle two-digit years, and we currently do so using 1970
as the break point. I've read recently that some industries are using a
"50/50 rule" for 2 digit conversions, where 1950 is the break point.
Don't know if we should try to use that (rather than the "Unix rule" :),
since it really doesn't offer a magic cure for all date possibilities.
> Only then we could declare pgsql as full Y2K compliant.
fwiw, the date candidates which are failing are outside the range of
normal usage or could be considered mal-formed. But I should be able to
get a fix in for it, and can post patches. Let me know what cases you
would like tested and fixed (but let's not bog down in discussion on
two-digit issues).
- Tom
