Skip to content

lint-has-time: improve annotation text #210

New issue

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

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

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 19, 2023
Merged

Conversation

evanelias
Copy link
Contributor

This commit improves lint-has-time's annotation message as follows:

  • For TIMESTAMP columns, mention the Y2K38 problem of this data type. Resolves new linter proposal: lint-y2k38 #209.

  • If the DB is running MySQL 5.7 (or older) or MariaDB 10.9 (or older), mention the upgrade complications involving explicit_defaults_for_timestamp for the first TIMESTAMP column in a table.

  • Explain that TIMESTAMP columns perform automatic UTC conversion for storage and retrieval, while DATETIME and TIME do not.

  • If lint-has-time=warning, omit the text about preferring ints instead of temporal types. This messaging only makes sense for companies who are strictly banning temporal types (lint-has-time=error), typically due to being stuck on a non-UTC time_zone setting which cannot be adjusted without skewing DATETIME values relative to TIMESTAMP values.

Web documentation for lint-has-time will also be expanded to cover these situations in more detail.

This commit improves lint-has-time's annotation message as follows:

* For TIMESTAMP columns, mention the Y2K38 problem of this data type.
  Resolves #209.

* If the DB is running MySQL 5.7 (or older) or MariaDB 10.9 (or older),
  mention the upgrade complications involving explicit_defaults_for_timestamp
  for the first TIMESTAMP column in a table.

* Explain that TIMESTAMP columns perform automatic UTC conversion for storage
  and retrieval, while DATETIME and TIME do not.

* If lint-has-time=warning, omit the text about preferring ints instead of
  temporal types. This messaging only makes sense for companies who are
  strictly banning temporal types (lint-has-time=error), typically due to
  being stuck on a non-UTC time_zone setting which cannot be adjusted without
  skewing DATETIME values relative to TIMESTAMP values.

Web documentation for lint-has-time will also be expanded to cover these
situations in more detail.
@coveralls-official
Copy link

Coverage Status

Coverage: 93.287% (-0.03%) from 93.312% when pulling 5455168 on lint-has-time-annotations into c15bee1 on main.

@evanelias evanelias merged commit 06969a3 into main Apr 19, 2023
@evanelias evanelias deleted the lint-has-time-annotations branch April 19, 2023 19:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

new linter proposal: lint-y2k38
1 participant