Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-22898

Date FieldTypes does not support time beyond 2038

    Details

      Description

      eZ Publish is currently using 32 bits dates, this causes problem for dates > 2038-01-19 or dates < 13-12-1901 20:45:52.

      The year 2038 problem may cause some computer software to fail at some point near the year 2038. The problem affects all software and systems that both store system time as a signed 32-bit integer, and interpret this number as the number of seconds since 00:00:00 UTC on Thursday, 1 January 1970.[1] The furthest time that can be represented this way is 03:14:07 UTC on Tuesday, 19 January 2038 (2147483647 seconds after January 1st, 1970).

      Times beyond this moment will "wrap around" and be stored internally as a negative number, which these systems will interpret as a date in December 13, 1901 rather than January 19, 2038. This is caused by integer overflow. The counter "runs out" of usable bits, "increments" the sign bit instead, and reports a maximally negative number (continuing to count up, toward zero). This is likely to cause problems for users of these systems due to erroneous calculations.

      Further, while most programs will only be affected in or very close to 2038, programs that work with future dates will begin to run into problems much sooner. For example, a program that works with dates 23 years in the future will have to be fixed no later than 2015.

      Because most 32-bit Unix-like systems store and manipulate time in this format, it is usually called Unix time, and so the year 2038 problem is often referred to as the Unix Millennium Bug.

        Issue Links

          Activity

          Hide
          Gunnstein Lye added a comment -

          This could be implemented by using PHP's 64-bit Date/Time classes: http://no.php.net/datetime
          The new stack already uses DateTime internally, but it's limited by the backwards compatible storage. The DB uses int(11) for ezdatetime timestamps, which isn't enough for full 64-bit DateTime. So the new stack fieldtypes uses 'U' as format string, limiting themselves to the range of valid Unix timestamps.

          An implementation for the date fieldtypes requires either a DB schema change, or a change in which DB column of ezcontentobject_attribute to use, from data_int to data_text. (Such a change obviously have consequences: Sorting and comparisons change, and presumably becomes slower.)

          The fieldtypes are only part of the picture. Unix timestamp are used all over in eZ Publish for create and modify times, which affect all manner of processes in new stack and legacy - for example delayed publishing workflows. A complete 64-bit date/time implementation requires code and DB schema changes for all of these, making this issue a major one.

          Since the current 2038 limitation is documented (e.g. Date), this reported issue is an improvement/feature request. As such it will be considered by the project management for possible future implementation.

          Possible workarounds for the fieldtypes include the existing legacy datatype "Birthday": http://projects.ez.no/birthday
          This kind of solution can of course also be implemented as a new stack fieldtype, by those who are so inclined.

          Show
          Gunnstein Lye added a comment - This could be implemented by using PHP's 64-bit Date/Time classes: http://no.php.net/datetime The new stack already uses DateTime internally, but it's limited by the backwards compatible storage. The DB uses int(11) for ezdatetime timestamps, which isn't enough for full 64-bit DateTime. So the new stack fieldtypes uses 'U' as format string, limiting themselves to the range of valid Unix timestamps. An implementation for the date fieldtypes requires either a DB schema change, or a change in which DB column of ezcontentobject_attribute to use, from data_int to data_text. (Such a change obviously have consequences: Sorting and comparisons change, and presumably becomes slower.) The fieldtypes are only part of the picture. Unix timestamp are used all over in eZ Publish for create and modify times, which affect all manner of processes in new stack and legacy - for example delayed publishing workflows. A complete 64-bit date/time implementation requires code and DB schema changes for all of these, making this issue a major one. Since the current 2038 limitation is documented (e.g. Date ), this reported issue is an improvement/feature request. As such it will be considered by the project management for possible future implementation. Possible workarounds for the fieldtypes include the existing legacy datatype "Birthday": http://projects.ez.no/birthday This kind of solution can of course also be implemented as a new stack fieldtype, by those who are so inclined.

            People

            • Assignee:
              Unassigned
              Reporter:
              Pedro Resende (Inactive)
            • Votes:
              2 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 hours
                2h