Skip to content

time-date: add rule to check for time.Date usage #1327

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
May 22, 2025

Conversation

ccoVeille
Copy link
Contributor

This commit introduces a new rule to check for the usage of time.Date

The rule is added to report the usage of time.Date with non-decimal literals

Here the leading zeros that seem OK, forces the value to be octal literals.

time.Date(2023, 01, 02, 03, 04, 05, 06, time.UTC)

gofumpt formats the code like this when it encounters leading zeroes.

time.Date(2023, 0o1, 0o2, 0o3, 0o4, 0o5, 0o6, time.UTC)

The rule also reports anything that is not a decimal literal. Please take a look at the testdata file.

Closes #1326

@ccoVeille
Copy link
Contributor Author

Based on the different feedbacks I got, this PR should reconsidered.

Let's continue the discussion in the issue, where I gathered the feedbacks I got, and try to provide a replies to them

@ccoVeille ccoVeille closed this Apr 29, 2025
@ccoVeille
Copy link
Contributor Author

I'm closing it for now.

The time I spend on this is not a pure lost because I played with revive internals to sea with the test. I might come back later with suggestions I have for tests/until_test.go

@ccoVeille
Copy link
Contributor Author

Based on feedback provided here by @chavacava

I resurrect this PR, address the comment made by @denisvmedia. I might discard some of them if they are in contradiction with what @chavacava said. But each of them will be reviewed and have a comment.

So for now,let's consider it's a draft again

@ccoVeille ccoVeille reopened this May 3, 2025
@ccoVeille
Copy link
Contributor Author

I applied changes:

The confidence level now varies:

  • if someone uses 00-07, confidence is set to 0.5 as it's ok to use 00-07
  • if someone pads with at least two zeros (00dd), confidence is set to 1 as it's a cause of bug and confusion
  • otherwise the confidence level is set at 0.8 (so for things like 0o1, 1_3, 1e1 ...) as it's a strange way to use time.Date

Please let me know if these values are ok or not

@ccoVeille
Copy link
Contributor Author

@alexandear please review again.

@ccoVeille
Copy link
Contributor Author

I have pushed again by simplifying the logging logic

@ccoVeille
Copy link
Contributor Author

I apparently forgot to push back my changes 😅🤦‍♂️

@ccoVeille
Copy link
Contributor Author

@denisvmedia @alexandear @chavacava

Could you please review again?

@chavacava
Copy link
Collaborator

Still some markdown linter failures. I'll merge as soon as checks pass

This commit introduces a new rule to check for the usage of time.Date

The rule is added to report the usage of time.Date with non-decimal literals

Here the leading zeros that seems OK, forces the value to be octal literals.
time.Date(2023, 01, 02, 03, 04, 05, 06, time.UTC)

gofumpt formats the code like this when it encounters leading zeroes.
time.Date(2023, 0o1, 0o2, 0o3, 0o4, 0o5, 0o6, time.UTC)

The rule reports anything that is not a decimal literal.
@chavacava chavacava merged commit 3cac850 into mgechev:master May 22, 2025
8 checks passed
@ccoVeille ccoVeille deleted the time-date branch May 22, 2025 20:36
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.

report time.Date used with leading zeroes (so the octal notation)
4 participants