Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Set Explicit Default for all Timestamp Values in MySQL Schema #119

Closed
shawnhathaway opened this issue Feb 6, 2020 · 7 comments · Fixed by #3424
Closed

Set Explicit Default for all Timestamp Values in MySQL Schema #119

shawnhathaway opened this issue Feb 6, 2020 · 7 comments · Fixed by #3424

Comments

@shawnhathaway
Copy link
Contributor

shawnhathaway commented Feb 6, 2020

During the clusterMembership table schema creation, I found MySQL has some hidden default value behavior for Timestamp columns that are declared NOT NULL in some cases. This caused the schema to work correctly on my local mysql (version: 8.0.19 Homebrew) but failed on the server mysql (version: 5.7).

From https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_explicit_defaults_for_timestamp:

If explicit_defaults_for_timestamp is disabled, the server enables the nonstandard behaviors and handles TIMESTAMP columns as follows:

TIMESTAMP columns not explicitly declared with the NULL attribute are automatically declared with the NOT NULL attribute. Assigning such a column a value of NULL is permitted and sets the column to the current timestamp.

The first TIMESTAMP column in a table, if not explicitly declared with the NULL attribute or an explicit DEFAULT or ON UPDATE attribute, is automatically declared with the DEFAULT CURRENT_TIMESTAMP and ON UPDATE CURRENT_TIMESTAMP attributes.

TIMESTAMP columns following the first one, if not explicitly declared with the NULL attribute or an explicit DEFAULT attribute, are automatically declared as DEFAULT '0000-00-00 00:00:00' (the “zero” timestamp). For inserted rows that specify no explicit value for such a column, the column is assigned '0000-00-00 00:00:00' and no warning occurs.

Depending on whether strict SQL mode or the NO_ZERO_DATE SQL mode is enabled, a default value of '0000-00-00 00:00:00' may be invalid. Be aware that the TRADITIONAL SQL mode includes strict mode and NO_ZERO_DATE. See Section 5.1.10, “Server SQL Modes”.

@samarabbas
Copy link
Contributor

Moving to stabilization. This is backwards compatible change.

@samarabbas
Copy link
Contributor

@yiminc @wxing1292 can you confirm if this is still relevant?

@alexshtin alexshtin removed their assignment Jul 13, 2021
@wxing1292
Copy link
Contributor

we will re-evaluate this issue when supporting mysql 8.0

@yiminc
Copy link
Member

yiminc commented Feb 12, 2022

now server support mysql 8.0.19. #2210

@qiuyuzhou
Copy link

In temporal v1.7: TIMESTAMP DEFAULT '1970-01-01 00:00:01'

This don't work when the time zone is '+8:00', because it would be subtracted 8 hours when convert it to UTC time zone, then would be an invalid value.

In temporal master branch: TIMESTAMP DEFAULT '1970-01-01 00:00:01+00:00'

The timezone offset is only supported from mysql v8.0.19.
This format has failed on my mysql v8.0.13 server.

@robholland
Copy link
Contributor

Lets set it to '1970-01-02 00:00:01' so that it's safe against timezone adjustment but doesn't require any particular MySQL release.

@robholland
Copy link
Contributor

This is preventing install on the current MariaDB version on AWS RDS (10.6.8).

robholland added a commit that referenced this issue Sep 23, 2022
This avoids compatibility issues with differing versions of MySQL.

Using 24 hours after the minimum timestamp value allows for any timezone adjustment that MySQL would do to get a UTC value before storing. The timezone suffix is not supported by all current MySQL versions/derivatives.

Fixes #119
robholland added a commit that referenced this issue Oct 3, 2022
This avoids compatibility issues with differing versions of MySQL.

Using 24 hours after the minimum timestamp value allows for any timezone adjustment that MySQL would do to get a UTC value before storing. The timezone suffix is not supported by all current MySQL versions/derivatives.

Fixes #119
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants