On Sun, Oct 31, 2004 at 04:14:52PM -0500, Tom Lane wrote:
> That line of argument leads directly to the conclusion that we shouldn't
> allow timezone-less input strings at all, since it's unlikely that
> anyone would code their app to append a timezone spec only during the
> two hours a year when it actually matters. And wouldn't you rather have
> had the problem pointed out immediately on testing the app, rather than
> waiting till 1AM on a fall Sunday morning to find out it's broken?
The only issue is storing a timezone-less timestamp into a field that
is timestamp with timezone. Every other combination is easy to handle.
If you're doing this, isn't it an indication that your field is the
wrong type? It's just plain ambiguous no matter which way you put it.
Assuming UTC would be almost as valid.
We don't promote integers to other types of numbers, so maybe this
shouldn't be allowed either.
> For human users, there would be some value in acting this way, since
> it would serve to remind them of the issue only when it actually
> matters. Comments anyone?
Except that means your program will work all the time except for one or
two hours per year where it breaks. Chances are your testing is not
going to trip it...
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
