Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling DateTimes #37

Open
sjkelly opened this issue Jun 16, 2016 · 2 comments
Open

Handling DateTimes #37

sjkelly opened this issue Jun 16, 2016 · 2 comments

Comments

@sjkelly
Copy link
Contributor

sjkelly commented Jun 16, 2016

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

@iamed2
Copy link
Contributor

iamed2 commented Jun 16, 2016

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.

@sjkelly
Copy link
Contributor Author

sjkelly commented Jun 21, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants