I’m thinking of simply using a string in the format “+hh:mm” (or “-hh:mm”). Is this both necessary and sufficient?
Note: I don’t need to store the date or the time, just the timezone.
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Unfortunately PostgreSQL doesn’t offer a time zone data type, so you should probably use
text.intervalseems like a logical option at first glance, and it is appropriate for some uses. However, it fails to consider daylight savings time, nor does it consider the fact that different regions in the same UTC offset have different DST rules.There is not a 1:1 mapping from UTC offset back to time zone.
For example, the time zone for
Australia/Sydney(New South Wales) isUTC+10(EST), orUTC+11(EDT) during daylight savings time. Yes, that’s the same acronymESTthat the USA uses; time zone acronyms are non-unique in the tzdata database, which is why Pg has thetimezone_abbreviationssetting. Worse, Brisbane (Queensland) is at almost the same longditude and is inUTC+10 EST… but doesn’t have daylight savings, so sometime it’s at a-1offset to New South Wales during NSW’s DST.(Update: More recently Australia adopted an
Aprefix, so it usesAESTas its eastern states TZ acronym, butESTandWSTremain in common use).Confusing much?
If all you need to store is a UTC offset then an
intervalis appropriate. If you want to store a time zone, store it astext. It’s a pain to validate and to convert to a time zone offset at the moment, but at least it copes with DST.