Dne 19. 2. 2014 21:20 "Alvaro Herrera" <alvhe...@2ndquadrant.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
