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

[ccoVeille]

Is your feature request related to a problem? Please describe.

time.Date is often used with leading zeroes

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

This pattern is pretty common as it replicates the natural way a human would write dates.

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

This would be the way to define the date,

time.Date(2023, 1, 2, 3, 4, 5, 6, time.UTC)

It doesn't seem to be a real problem, but the following code cannot compile

time.Date(2023, 01, 02, 03, 08, 00, 00, time.UTC)

Here someone wanted to use 08:00:00 UTC time, but 08 is not a valid octal.

So some PR requires to change from octal notation to decimal one to be able to use 08 and 09

There is fortunately no conversion issues for number under 7 (octal range is 0-7)

Also, there is a real concern when gofumpt faces octal notation, it will transform it to this.

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

This pattern is not that common, but pretty ugly.

Describe the solution you'd like

A new rule to detect this.

Describe alternatives you've considered

• updating the code of gofumpt, it's strange to add exception for this in gofumpt code that is very simple
• adding exception to go-critic octalLiteral, the code is very simple, and the linter is not aware of how an octal is used, so it would require a lot of code change to check if we are in time.Date method

Additional context

I faced this when:

• I tried to use the time 08:00:00 and wrote time.Date(2023, 01, 02, 03, 08, 00, 00, time.UTC)
• gofumpt reformated some files

[ccoVeille]

A real life example of this could be this

time.Date(2026, 01, 31, 22, 04, 05, 001777777, time.UTC)
time.Date(2026, 07, 31, 22, 04, 05, 000777777, time.UTC)

Here the leading zeroes implies a strange behavior

https://go.dev/play/p/RQk4PtV66nm

You thought you asked for 777777 nanoseconds.

So you expected this

2026-07-31 22:04:05.001777777 +0000 UTC
2026-07-31 22:04:05.000777777 +0000 UTC

But you got this
2026-07-31 22:04:05.001777777 +0000 UTC
2026-07-31 22:04:05.000262143 +0000 UTC

[alexandear]

Thanks for the detailed report — the rationale and examples are very clear.

Could we report only values with zeros that are greater than 09?

00, 01, 02, 03, 04, 05, 06, 07, 08, 09 - fine.

001777777 - not fine.

[ccoVeille]

Thanks you @alexandear about your feedback.

I wouldikd to thank @denisvmedia about the feedbacks he made on the PR

If a person deliberately set it to octal, then I think in this case it's a style issue, not a real problem. So, I'm not sure we should do it in this linter rule.

• time-date: add rule to check for time.Date usage #1327 (comment)
• time-date: add rule to check for time.Date usage #1327 (comment)

You are both right. I might go too far with this style issue.

Let's consider the following statements:

About time.Date

• there is indeed no problem with having octal notation 01-07 with time.Date
• reporting the usage of 00-07 with time.Date doesn't make sense.
• reporting them would have impact on a lot of valid code, they would be considered as false-negative and opionated
• 08 and 09 are forbidden by go compiler, so there is nothing to do about them
• if people want to use unusual integer literal with time.Date is stylistic opinion
• the only one that could be considered is the fact 0o1-0o7 are odd to use with time.Date

About gofumpt

• having gofumpt that transform "old octal notation" to "new octal notation" is only a stylistic issue, as it looks odd to see 0o0 - 0o7 used with time.Date once gofumpt format them.
• opening an issue on gofumpt about this should be considered about this.

About leading octal with multiple leading 00

• having an octal written with at least two leading zero bigger than 7 is a source of bug, and here it's not about time.Date only.
• a new linter could be created about it.

Depending on your feedbacks about these, I would do changes to my code

[denisvmedia]

To summarize: we should distinguish between a potential bug and a style issue. While I do support checking for both, I'm not sure it should belong to one and the same linter. At the same time, building different linters for this is overkill. In fact, the style issue can be a part of go-critic maybe. But the error case can be done in revive. I don't have a strong opinion though.

[ccoVeille]

I'm facing a strange situation then.

Because the linter in the way I thought initially was doing a lot of things and would now be limited to use only possible bug detection with leading zero for the nanoseconds.

I feel like it would report very few things. But they are likely to be error I think.

So is there a need for such linter?

[ccoVeille]

I looked at go-critic again and I think it's a good candidate for the 0o0-0o7 and maybe the 00-07 one too.

I will open a PR to octal notation.

But I also feel like I may have a PR to open in gofumpt

[chavacava]

there is indeed no problem with having octal notation 01-07 with time.Date

There is no problem but, as you mention in your first post, most of the time it's an "accidental" use of octal notation; i.e., we write 01-07 thinking on them as decimal notation.

reporting the usage of 00-07 with time.Date doesn't make sense.

Personally, I'll found useful if a tool tells me "hey, Do you known that these are octal and not decimal?"
(and 99% of the times I'll say "oh, thanks, it was not my intent")

reporting them would have impact on a lot of valid code, they would be considered as false-negative and opionated

we can use confidence to handle these cases. "hey, I might be wrong (low confidence) but that smells your are using octal notation by accident"

if people want to use unusual integer literal with time.Date is stylistic opinion

I think 99.99% of the people uses decimal notation. I don't see a problem if false positives affect the other 0.01%.

To resume: I think the rule has its place in revive. (Potentially) stylistic errors could be reported with low confidence and actual errors (like 000777777) with high confidence.

[ccoVeille]

About gofumpt\n\nhaving gofumpt that transform "old octal notation" to "new octal notation" is only a stylistic issue, as it looks odd to see 0o0 - 0o7 used with time.Date once gofumpt format them.\nopening an issue on gofumpt about this should be considered about this.

gofumpt maintainer is not interested by doing extra work to fix octal usage with time.Date

• octal vs misuage of time.Date mvdan/gofumpt#323 (comment)