Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-39096

SAKAI_USER MySQL TIMESTAMP should be DATETIME

    Details

    • Type: Bug
    • Status: Verified
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 11.4
    • Fix Version/s: 12.0, 19.0
    • Component/s: Kernel
    • Labels:
    • 12 status:
      Resolved
    • Previous Issue Keys:
      KNL-1566
    • Test Plan:
      Hide

      Please add a Test Plan here.

      Show
      Please add a Test Plan here.

      Description

      CREATE TABLE SAKAI_USER
      (
      USER_ID VARCHAR (99) NOT NULL,
      EMAIL VARCHAR (255) NULL,
      EMAIL_LC VARCHAR (255) NULL,
      FIRST_NAME VARCHAR (255) NULL,
      LAST_NAME VARCHAR (255) NULL,
      TYPE VARCHAR (255) NULL,
      PW VARCHAR (255) NULL,
      CREATEDBY VARCHAR (99) NOT NULL,
      MODIFIEDBY VARCHAR (99) NOT NULL,
      CREATEDON TIMESTAMP NOT NULL,
      MODIFIEDON DATETIME NOT NULL
      );

      https://dev.mysql.com/doc/refman/5.7/en/datetime.html

      "A DATETIME or TIMESTAMP value can include a trailing fractional seconds part in up to microseconds (6 digits) precision. In particular, any fractional part in a value inserted into a DATETIME or TIMESTAMP column is stored rather than discarded. With the fractional part included, the format for these values is 'YYYY-MM-DD HH:MM:SS[.fraction]', the range for DATETIME values is '1000-01-01 00:00:00.000000' to '9999-12-31 23:59:59.999999', and the range for TIMESTAMP values is '1970-01-01 00:00:01.000000' to '2038-01-19 03:14:07.999999'. The fractional part should always be separated from the rest of the time by a decimal point; no other fractional seconds delimiter is recognized. For information about fractional seconds support in MySQL, see Section 11.3.6, “Fractional Seconds in Time Values”.

      The TIMESTAMP and DATETIME data types offer automatic initialization and updating to the current date and time. For more information, see Section 11.3.5, “Automatic Initialization and Updating for TIMESTAMP and DATETIME”.

      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. For more information, see Section 10.6, “MySQL Server Time Zone Support”."

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                dhorwitz David Horwitz
                Reporter:
                dhorwitz David Horwitz
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Git Source Code