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

Postgres returning bad dates, related to datestyle? #287

Closed
baderstine opened this issue Jan 20, 2021 · 5 comments · Fixed by #288
Closed

Postgres returning bad dates, related to datestyle? #287

baderstine opened this issue Jan 20, 2021 · 5 comments · Fixed by #288

Comments

@baderstine
Copy link
Contributor

baderstine commented Jan 20, 2021

Postgres returning dates/timestamps as very different from database values using R (3.6.3).

Within pgAdmin 4.x the source column value is:
2018-07-27 09:19:43 (column type is "timestamp without time zone")

con  = RPostgres::dbConnect(RPostgres::Postgres(), 
                            host ..., 
                            port ..., 
                            dbname ..., 
                            user ..., 
                            password ..., 
                            sslmode = 'require', 
                            timezone = NULL)

dbGetQuery(con, "select tzcolumn from tablename limit 1")

Using RPostgres 1.2.0 returns 2719-03-09 05:40:03

Using RPostgres 1.3.1 returns 2719-04-22 05:40:03

Also get really strange results from my db when running test-timezone.R, which really seems like a date formatting issue:

>   query <- "SELECT '2018-01-01 12:30:00'::TIMESTAMP AS a, '2018-01-01 12:30:00'::TIMESTAMPTZ AS b"
>   DBI::dbGetQuery(con, query)
                    a                   b
1 0120-12-21 06:10:00 0120-12-21 00:37:49

I noticed the same issue with date formatted columns.
source : output
"2010-04-10" : "1015-01-05",
"2009-12-30" : "3005-09-10"

In PgAdmin, I ran show datestyle and it returned "ISO, DMY".
On a different PostgreSQL database that I connect to using RPostgres (without SSL, not sure if that's relevant), show datestyle returns "ISO, MDY" and queries of this database return perfectly normal results for all of the above queries (timestamps, etc. are correct).

It seems that the first two characters of the returned date value are always the "day" of the original date, but cannot sort out how the other date characters are determined.

@baderstine
Copy link
Contributor Author

baderstine commented Jan 20, 2021

Another head-scratcher:
DBI::dbGetQuery(con, "SELECT current_date;") returns

  current_date
1   2020-09-08

today is 2020-01-20, aka 20-01-2020 (DMY), aka 01-20-2020 (MDY)

@baderstine
Copy link
Contributor Author

baderstine commented Jan 20, 2021

@krlmlr you were right about datestyle it seems:

Not sure why I didn't try this earlier.
DBI::dbGetQuery(con, "show datestyle") returns

           DateStyle
1 Redwood, SHOW_TIME

If I explicitly set the datestyle then all subsequent results have properly formatted dates and times.
DBI::dbExecute(con, "set datestyle to iso, mdy;")

@krlmlr
Copy link
Member

krlmlr commented Jan 21, 2021

Thanks. So the workaround seems obvious: issue a set datestyle query after connecting; we could also do this ourselves in dbConnect() .

The question remains why libpq relies on this configuration, and how to retrieve values via libpq that work regardless of this configuration. It might be impossible, then the workaround is all that remains.

Would you like to contribute a pull request?

@baderstine
Copy link
Contributor Author

sure, can do.

baderstine added a commit to baderstine/RPostgres that referenced this issue Jan 21, 2021
krlmlr added a commit that referenced this issue Jan 22, 2021
- `dbConnect()` now issues `SET datestyle to iso, mdy` to avoid translation errors for datetime values with databases configured differently (#287, @baderstine).
@github-actions
Copy link
Contributor

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue and link to this old issue if necessary.

@github-actions github-actions bot locked and limited conversation to collaborators Jan 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants