Description
Preconditions (*)
Read the mysql documentation around the usage for datetime and timestamp field types
Especially these sections are important:
The DATETIME type is used for values that contain both date and time parts. MySQL retrieves and displays DATETIME values in 'YYYY-MM-DD hh:mm:ss' format. The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'.
The TIMESTAMP data type is used for values that contain both date and time parts. TIMESTAMP has a range of '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC.
MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval. (This does not occur for other types such as DATETIME.) By default, the current time zone for each connection is the server's time. The time zone can be set on a per-connection basis. As long as the time zone setting remains constant, you get back the same value you store. If you store a TIMESTAMP value, and then change the time zone and retrieve the value, the retrieved value is different from the value you stored. This occurs because the same time zone was not used for conversion in both directions. The current time zone is available as the value of the time_zone system variable.
Be aware of the difference in timezone handling between these type of fields, that might be important, but it's hard to predict without proper testing how they will behave within Magento
Steps to reproduce (*)
- Look into the source code of Magento
- Search for usages of 'timestamp' or 'datetime', I currently find these numbers (both in real code as in testing code):
- 20 usages of datetime
- 146 usages of timestamp
Expected result (*)
- The appropriate field should be used in the appropriate place. When we expect that a field might contain a value beyond the year 2038, we should change it from timestamp to datetime
Actual result (*)
- Currently a lot of fields in the database can't contain dates beyond the year 2038
References
This was already noticed at least twice previously in the magento codebase:
- Magento 2.2.6 coupon codes don't work anymore #18183 (comment) (fixed in: Resolved issue coupon codes don't work anymore #18183 #22718)
- New admin account is disabled after a login attempt is made if the account's expiration date is greater than 2038 #34463 (proposed fix: Update expires_at column type from table admin_user_expiration in ord… #34462)
Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.
- Severity: S0 - Affects critical data or functionality and leaves users without workaround.
- Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
- Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
- Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
- Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status