Open sjkelly opened 8 years ago
It's fine to bring TimeZones.jl in I think. Anything that loses information (e.g. lossy conversion to DateTime from TIMESTAMP WITH TIME ZONE) should be left up to the user.
An update: I noticed that timestamps were just returned as strings, so I did the same for time stamps with time zones. This patch is in #38. There are a few formats time stamps may take: https://www.postgresql.org/docs/9.1/static/datatype-datetime.html#DATATYPE-DATETIME-OUTPUT-TABLE. This is set in the config: https://www.postgresql.org/docs/9.1/static/runtime-config-client.html#GUC-DATESTYLE.
I think the most robust approach here is to handle parsing based on the config, followed by the existing method of returning a string (leaving the DateTime/DateTimeTZ conversion up to the developer). The parsing based on the config is a little more intricate, so I did not attempt it yet.
I have noticed that OID 1184 (TIMESTAMPTZOID) is unsupported. I will give it a try to add this either today or tomorrow. My question is if timezones should be handled with standard library and be converted to a
DateTime
or should we bring in a time zone library? I am a database newbie, so I'd appreciate any advice.CC @iamed2