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

inconsistent behavior of Row.Scan scanning time.Time struct #251

Open
nashtsai opened this issue Apr 20, 2014 · 4 comments
Open

inconsistent behavior of Row.Scan scanning time.Time struct #251

nashtsai opened this issue Apr 20, 2014 · 4 comments

Comments

@nashtsai
Copy link

inconsistent behavior of Row.Scan scanning time.Time struct, where db schema as following:
Table "public.all_cols"
Column | Type | Modifiers
--------------+-----------------------------+-----------------------------------------------------------
time | time without time zone |
time_stamp | timestamp without time zone |
time_stamp_z | timestamp with time zone |

it's discovered that 'time' column will scanned as:
0000-01-01 22:20:59 +0000 UTC

and 'time_stamp' column is scanned as:
2014-04-20 22:20:59 +0000 +0000

all above times are my local time(+8000). If there is no timezone info, then 'time' column scanned as Time struct shouldn't set the Location to UTC.

@johto
Copy link
Contributor

johto commented Apr 20, 2014

Yeah, this seems like a bug. I wonder if it would be enough to just set the location to +00 here.

@johto
Copy link
Contributor

johto commented Apr 20, 2014

Oops. This is the correct place, of course.

@pkieltyka
Copy link

hello, is this bug still relevant? I've also noticed timestamps returning as 2014-04-20 22:20:59 +0000 +0000

@johto
Copy link
Contributor

johto commented Mar 1, 2015

For timestamps "+0000 +0000" is the correct answer for now. Though there are discussions about possibly changing it in #329.

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

Successfully merging a pull request may close this issue.

3 participants