> 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?
