-
Notifications
You must be signed in to change notification settings - Fork 10.7k
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
[12.x] fix: update postgres grammar date format #51363
base: master
Are you sure you want to change the base?
Conversation
72d3ec3
to
567bc3f
Compare
Can we make this change on a patch release? Seems breaking? |
Postgres only converts the datetime to UTC when the field contains a timezone (e.g.,
Thus, the conversion should only affect fields with timezones, which if people are using then they would already have to be manually converting the Carbon instances to UTC or their datetimes would be incorrect. Also, if the timestamp precision is not 6, then Postgres will round up the microseconds (per typical rounding rules) to the appropriate precision:
This should be fine in Production, however, this might cause some tests to fail by a second difference if they're, say, comparing a I suppose to be on the safe side it would be better to merge to 12.x. |
I also think the best is to target this at 12.x |
567bc3f
to
e5373fb
Compare
Updated target to 12.x |
Make sure to mark this PR as ready if you need another review. |
I encountered the issue before too but changing it by default resulted in bc breaks in edge cases. As microseconds and timezones are not used often, I am not sure whether we should complicate it. Especially as MySQL and PostgreSQL will then from now on (with default settings) behave differently. I solved this in my extended PostgreSQL driver by using traits which is an easy thing to implement. So anyone departing from the default can change the model. But I personally would like to not add more behavioural differences between using MySQL and PostgreSQL. |
Hello!
PostgreSQL supports
time[stamp] with time zone
fields with a resolution of 1 microsecond. However, the default grammar date format isY-m-d H:i:s
which truncatesDateTimeInterface
objects that are passed to queries.This results in invalid queries and records being saved to / returned from the database. For example:
This PR updates the PostgresGrammar date format to prevent the lose of information:
Thanks!