When saving an entity containing a date field with a far value (after 2035), an PDOException occurs :
PDOException: SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value for column ...
It seems the the database column created by adding a date field on an entity is to small (int(11)) to contain the value of far dates.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | date-far_dates_causes_pdo_exception-2016787-15.patch | 898 bytes | pio.fernandes |
| #9 | date-n2016787-9.patch | 976 bytes | damienmckenna |
| #9 | date-n2016787-9.interdiff.txt | 381 bytes | damienmckenna |
| #5 | date-far_dates_causes_pdo_exception-2016787-5.patch | 1019 bytes | r-mo |
| #4 | date-far_dates_causes_pdo_exception-2016787-4.patch | 987 bytes | r-mo |
Comments
Comment #1
heddnThe largest date that can be stored in a mysql int column is unix timestamp 2147483647 (Tue, 19 Jan 2038 03:14:07 GMT). Probably should catch that at form validation.
Comment #2
r-mo commentedAny reason not to update schema to use big integer?
Comment #3
damienmckennaThis is a great improvement, thank you.
One suggestions is that the old field_schema may be cached when the update script runs, therefore it might not get the "size => big" setting. As a result I suggest adding $schema['size'] = 'big'; before the two db_change_field() calls.
Comment #4
r-mo commentedI'd thought of that might be needed but tested the update it seemed to pull in the correct schema without any cache clears. No problem to ensure it's set just in case.
Comment #5
r-mo commentedComment #6
Anonymous (not verified) commentedComment #7
Anonymous (not verified) commented#5 works as advertised.
Thanks!
Comment #8
damienmckennaI want to manually test this on a site with lots of data, to make sure it doesn't time out, but otherwise this looks pretty good.
Comment #9
damienmckennaA quick reroll as update script 7006 was taken by another issue.
Comment #10
damienmckennaCommitted. Thank you all.
Comment #13
pio.fernandes commentedHi, this patch works, but not entirely for me: In my case there's a column of type varchar (called timezone) that should no be submitted to the db_change_field()
Adding new patch
Comment #14
pio.fernandes commentedComment #15
pio.fernandes commentedComment #16
steven jones commentedAnd this update is very likely to cause issues for people using non standard field storage backends, since those tables that the code is trying to change may simply not exist.
Comment #17
solideogloria commentedPlease open a new issue referencing this one if you have a problem. This issue is closed and only maintainers can reopen it.