Unix time stamps, short (int) or long res, are always supposed to GMT based, as far as I know - I never seen anything different, except maybe in homebrew software. So it should be both calendar and P.I.T. And you wouldn't need the TZ storage if the date-number and number-> translation itself takes the TZ arg so that it can localize the Human String for you.
Ken
In fact, I would suggest that if there is any function, or field, that takes a TZ-less argument (*especially* if it takes only the number), that its name should be made to contain 'UTC' so clearly disambiguate whats its intended use for (since zone-less values/fields SHOULD be regarded as UTC) - Otherwise, some users will place epoch numbers adjusted for the their timezone in the field (and even with daylight saving offsets applies, somewhat amusingly but wrong). So then two different users are using the exact same datatype for inconsistent types. (just a concern for interoperability, user awareness, and when an employee comes on-board and has to deal with bad legacy)
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
