Change all core timestamps to use BIGINT instead of INT (for the 2038 problem) #6931
Description
Description of the need
I know we're still some years away from having to worry about it, but it never hurts to be prepared. I want to suggest changing all of the core database fields that use INT (like user.created, node.created, node.changed, etc) to use BIGINT instead.
This issue touched on the problem, but only for fields: #6307
Obviously there isn't a huge rush-- we have over a decade to make this relatively small change-- but I didn't see any other issues already in place for it.
Proposed solution
In new versions of Backdrop, when an INT is being used for a timestamp, change to use BIGINT instead. Ex: user.created, node.created, watchdog entries, etc.
Alternatives that have been considered
Possibly use "DATETIME" instead of INT entirely, as it certainly makes it more human-readable. There are lots of good arguments to be made for using DATETIME to store dates & times, like not having to rely on PHP to convert to a human-readable format before displaying on screen. Exporting watchdog as a CSV becomes a instant audit log, etc. Plus people online make fun of me when I tell them I store dates as INTs 😥
Using DATETIME would of course be a backwards compatibility-breaking departure from Drupal though. Maybe best saved for Backdrop 2x.
IIRC, Drupal only used INT in the first place because they meant to support several different database products, not all of which have a true "date" or "datetime" data type. Since it seems that Backdrop only supports MySQL/MariaDB for core, this isn't really an issue.