Re: Fwd: patch: make_timestamp function

Dne 19. 2. 2014 21:20 "Alvaro Herrera" <alvherre(at)2ndquadrant(dot)com> napsal(a):
>
> Pavel Stehule escribió:
>
> > I though about it, and now I am thinking so timezone in format
> > 'Europe/Prague' is together with time ambiguous
> >
> > We can do it, but we have to expect so calculation will be related to
> > current date - and I am not sure if it is correct, because someone can
> > write some like
> >
> > make_date(x,x,x) + make_timetz(..) - and result will be damaged.
>
> Hmm, I see your point --- the make_timetz() call would use today's
> timezone displacement, which might be different from the one used in the
> make_date() result. That would result in a botched timestamptz
> sometimes, but it might escape testing because it's subtle and depends
> on the input data.
>
> However, your proposal is to use an abbreviation timezone, thereby
> forcing the user to select the correct timezone i.e. the one that
> matches the make_date() arguments. I'm not sure this is much of an
> improvement, because then the user is faced with the difficult problem
> of figuring out the correct abbreviation in the first place.
>
> I think there is little we can do to solve the problem at this level; it
> seems to me that the right solution here is to instruct users to use
> make_date() only in conjunction with make_time(), that is, produce a
> timezone-less timestamp; and then apply a AT TIME ZONE operator to the
> result. That could take a full timezone name, and that would always
> work correctly.
>
> My conclusion here is that the "time with time zone" datatype is broken
> in itself, because of this kind of ambiguity. Maybe we should just
> avoid offering more functionality on top of it, that is get rid of
> make_timetz() in this patch?
>

+1

Pavel
> --
> Álvaro Herrera http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services