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

Timezone is stripped from time.Time when inserting into Postgres #96

Closed
kvap opened this issue Jul 4, 2017 · 5 comments
Closed

Timezone is stripped from time.Time when inserting into Postgres #96

kvap opened this issue Jul 4, 2017 · 5 comments
Labels

Comments

@kvap
Copy link

kvap commented Jul 4, 2017

gocraft/dbr implements time serialization incorrectly, it strips the time zone away from time.Time, which results in wrong time stored in the database.

@KumanoTanaka
Copy link

KumanoTanaka commented Jul 8, 2017

https://github.com/gocraft/dbr/blob/master/dialect/mysql.go#L57

func (d mysql) EncodeTime(t time.Time) string {
    return `'` + t.UTC().Format(timeFormat) + `'`
}

↓ (I want to change this line above to below...)

func (d mysql) EncodeTime(t time.Time) string {
    return `'` + t.Format(timeFormat) + `'`
}

this may fix wrong time Create/Update problem not only in postgres but also in Mysql.

buuut.. I found the following comment
#40 (comment)

maybe we should create our own dialect(??)...

@taylorchu
Copy link
Contributor

We use UTC() for backward compatibility. You can create your dialect by embedding the dialect type.

@davisdevs
Copy link

We use UTC() for backward compatibility. You can create your dialect by embedding the dialect type.

I understand using UTC() for backward compatibility.

For me, using UTC() is not an issue If the timezone is in timeFormat, as PostgresSQL would convert to the db timezone.

However, is it also for backward compatibility reasons that the timezone is stripped from timeFormat?
https://github.com/gocraft/dbr/blob/master/now.go#L11

const timeFormat = "2006-01-02 15:04:05.000000"

If so, this is a dangerous function to call and I (embarrassingly) missed the timezone stripping. A low-hanging fruit would be having a comment highlighting that it is using UTC() and timezone agnostic?

@stale
Copy link

stale bot commented Oct 15, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Oct 15, 2018
@stale stale bot closed this as completed Oct 23, 2018
@mcesar
Copy link

mcesar commented Dec 27, 2018

We use UTC() for backward compatibility. You can create your dialect by embedding the dialect type.

How? The dialect type is not exported...

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

No branches or pull requests

5 participants