|Anonymous | Login | Signup for a new account||2017-01-22 19:13 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001389||RackTables||default||public||2015-01-08 23:17||2016-08-02 00:09|
|Platform||x86||OS||Debian Linux||OS Version|
|Target Version||0.20.12||Fixed in Version||0.20.12|
|Summary||0001389: Date field has upper date boundry|
|Description||When entering a warranty expiration that is dramatically in the future (example: 2109-08-26) the year gets rewritten without any user alert. |
Dates this far in the future are common to HP networking components, which have 'lifetime' warranties.
|Steps To Reproduce||Locate an object with a date field.|
Enter a date far into the future, example: "2109-08-26"
The date will now read "2106-02-07"
|Additional Information||I have not tested a lower bound for the date field.|
|Tags||No tags attached.|
edited on: 2015-05-19 06:22
The date 2106-02-07 is an unsigned 32bit integer's maximum value, used as a Unix timestamp - 4294967295 seconds since January 1st 1970.
In the RackTables database, the AttributeValue table, the column "uint_value" is type "int(10) unsigned".
If that's right, the database column would need to be a "bigint(20)" or "bigint(20) unsigned" type to store later dates (or dates would need to be stored in a different form entirely).
(Because of this, there is a lower bound for the date field as well.
1970-01-02 is stored, 1970-01-01 and earlier says 'updated successfully', but the field comes back empty).
(This is reproducible on 64-bit CentOS 6 running 64-bit PHP 5.3, and on the RackTables demo interface running RackTables 0.20.10)
|Definitely the conversion error should result in a warning/error message. But would it be reasonable to expect RackTables to handle the dates beyond the range explained in the previous comment?|
As it had been discussed in detail in an earlier comment, the problem is indeed specific to a date outside of the 1970-01-01T00:00:00Z~2106-02-07T06:28:15Z range (in other words, with the UNIX time not in the 0x00000000~0xFFFFFFFF range).
When requested to store such a UNIX time into a 32-bit unsigned integer column, your instance of MySQL seems to truncate the value silently but mine returns an error, which results in a PDO exception:
SQLSTATE: Numeric value out of range: 1264 Out of range value for column 'uint_value' at row 1 (22003)
Commit b204a89 makes the existing date range limit work as expected (that is, to display a meaningful error message and leave the old value intact) before and if the database layer is extended to allow the dates beyond the existing limit shown above. That said, the latter is very unlikely to happen in a near future unless anybody is willing to spend their time on this feature.
To allow for any additional feedback this issue should remain open for a few extra months.
|Closing the issue for now as explained above.|
|2015-01-08 23:17||hackmaster||New Issue|
|2015-05-18 23:02||simon2||Note Added: 0002829|
|2015-05-19 06:22||simon2||Note Edited: 0002829||View Revisions|
|2016-05-19 17:15||infrastation||Note Added: 0003205|
|2016-06-10 13:14||infrastation||Note Added: 0003229|
|2016-06-10 13:14||infrastation||Priority||normal => low|
|2016-06-10 13:14||infrastation||Status||new => acknowledged|
|2016-06-10 13:14||infrastation||Resolution||open => suspended|
|2016-06-10 13:14||infrastation||Fixed in Version||=> 0.20.12|
|2016-06-10 13:14||infrastation||Target Version||=> 0.20.12|
|2016-08-02 00:09||infrastation||Note Added: 0003419|
|2016-08-02 00:09||infrastation||Assigned To||=> infrastation|
|2016-08-02 00:09||infrastation||Status||acknowledged => closed|
|2016-08-02 00:09||infrastation||Resolution||suspended => fixed|
|Copyright © 2000 - 2017 MantisBT Team|