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

[5.5] Change datetime to datetime2 #18962

Merged
merged 3 commits into from Apr 27, 2017
Merged

[5.5] Change datetime to datetime2 #18962

merged 3 commits into from Apr 27, 2017

Conversation

fernandobandeira
Copy link
Contributor

@fernandobandeira fernandobandeira commented Apr 27, 2017

Previous PR #18847 added a precision parameter to the datetime column, however this parameter isn't supported by SQLServer.

Instead of reverting the change we can change the column used by the Schema builder to datetime2 this column is available since SQLServer 2008 and supports the precision parameter.

Link to datetime docs
Link to datetime2 docs

datetime2 can be considered as an extension of the existing datetime type that has a larger date range, a larger default fractional precision, and optional user-specified precision.

@taylorotwell taylorotwell merged commit a9cb9ef into laravel:master Apr 27, 2017
@sisve
Copy link
Contributor

sisve commented Apr 28, 2017

Wouldn't this be a breaking change? I've already executed migrations with $table->datetime('...') in production, and they are the old datetime type, and after the upgrade to 5.5 my migrations will generate table schemas that no longer matches production. Everytime I rebuild my vagrant machine/development environment I would get a table schema that does not match what the migration generated when it was written.

@fernandobandeira fernandobandeira deleted the patch-1 branch April 28, 2017 11:25
@fernandobandeira
Copy link
Contributor Author

fernandobandeira commented Apr 28, 2017

@sisve It shouldn't cause trouble for anyone using it since the only difference is that datetime2 has a larger default fractional precision, it would break only for this specific usecase:

If you are saving a datetime like 9999-12-31 23:59:59.9999999 previously you would end with a record of 9999-12-31 23:59:59.997 now it'll correctly save the date with all the fraction precision, this is quite an edge usecase, but it can indeed break if you are comparing if two date's are equal between an old table and a new table (generated after migrating to 5.5).

We would need to change it eventually to match the behavior of the other drivers since before my PR the migration for the datetime was broken since the parameter precision isn't supported for the datetime field.

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 this pull request may close these issues.

None yet

3 participants