cmd/vet: check for time formats with 2006-02-01 #48801
Comments
|
I don't think "isn't really used" meets the precision bar for vet |
seankhliao
changed the title
|
We would need some evidence of frequency to put this in. Is there any? |
|
This proposal has been added to the active column of the proposals project |
|
There is a lots of projects on Github with this issue: https://github.com/search?l=GO&q=%222006-02-01%22+language%3AGo&type=Code Even bigger projects have or had bad code: |
|
That's pretty surprising but it does seem to meet the vet bars:
|
|
The buffalo link is a test and specifically follows the 2006-02-01 line checking that 2017-01-10 is parsed as October 1st. The couchbase code looks to be code that generates database entries, and I wouldn't be surprised if it's deliberately choosing the US date format. Some other code in the first page of that search is explicitly using US format: I've in the past run into YYYY-DD-MM and MM-DD-YYYY when dealing with government forms (which was highly confusing, personally). I think this might be a good signal some of time, but would have false positives. I also feel that anybody that knows the 2006, 01, and 02 numbers also knows the documentation mentioning that 01 is the month and 02 is the day (or, if they're like me, the person looks up what 01 and 02 refer to every time they need to format a time in Go). I'd bet that more often than not, the choice of 02 and 01 is deliberate. If anything, this feels like a check more suited for a linter that an org / teams could opt into, rather than a default check that cannot be opted out of. |
|
@twmb can you give specific examples of uses of YYYY-DD-MM? The buffalo link and test looks like a bug to me, compounded by someone taking the output and hard-coding that as the expected answer. Similarly, the jserranojunior link looks like a bug. The date is parsed and then reformatted using the same 2006-02-01 format, so you wouldn't notice for many dates that it was wrong. (Up until the 13th of the month it would pass through just fine.) I don't understand the reference to YYYY-DD-MM as "US format". I have lived in the US my whole life and never seen a date written that way. Halloween is 10/31 or 10-31 not 31-10 or 31/10 and definitely not 2021-31-10. |
|
https://stackoverflow.com/questions/2254014/are-there-locales-or-common-programs-that-use-yyyy-dd-mm-as-the-date-format points to a wikipedia entry: https://en.wikipedia.org/wiki/Date_format_by_country. It states for Kazakhstan:
Like the SO post I also cannot read the citation for this. "yyyy.dd.mm" is close but uses a different delimiter ("." instead of "-"). |
|
I tried to make sense of the document but Google Translate doesn't really help. The specific section is: Which translates to: But since the author(s) on Wikipedia specifically use |
|
Based on the discussion above, this proposal seems like a likely accept. |
|
No change in consensus, so accepted. 🎉 |
rsc
changed the title
|
That is great to hear. I already suggested an implementation here: https://go-review.googlesource.com/c/tools/+/354010 (and here: golang/tools#342) |
|
There is a little chance of false positive in places that had to provide compatibility with such erroneous format. For example, we can find such in LLVM code (which is still a bug), in some weird Apache tests and other places (?). Adding this to go vet is unfortunate, IMO this should be implemented as linter that at least supports suppression. |
|
@ernado As seen above there is Go code that erroneously uses this format, so the vet check is useful. Your examples are not Go code, so it's hard to know how significant those cases are. It will be possible to avoid the vet check by using a variable rather than a constant. |
|
Agree, thank you. |
|
The LLVM code says |
|
If "2006-01-02" is worthy of a vet check, is it also worthy of a constant? Maybe |
|
I'm not sure, none of the other formats have separate constants for the datetime and just the date. |
yyyy-dd-mm is a time format that isn't really used anywhere [1]. It is much more likely that the user intended to use yyyy-mm-dd instead and made a mistake. This happens quite often [2] because of the unusual way to handle time formatting and parsing in Go. Since the mistake is Go specific and happens so often a vet check will be useful. Updates golang/go#48801 1. https://stackoverflow.com/questions/2254014/are-there-locales-or-common-programs-that-use-yyyy-dd-mm-as-the-date-format 2. https://github.com/search?l=&p=1&q=%222006-02-01%22+language%3AGo&type=Code
Updates golang/go#48801 yyyy-dd-mm is a time format that isn't really used anywhere [1]. It is much more likely that the user intended to use yyyy-mm-dd instead and made a mistake. This happens quite often [2] because of the unusual way to handle time formatting and parsing in Go. Since the mistake is Go specific and happens so often a vet check will be useful. 1. https://stackoverflow.com/questions/2254014/are-there-locales-or-common-programs-that-use-yyyy-dd-mm-as-the-date-format 2. https://github.com/search?l=&p=1&q=%222006-02-01%22+language%3AGo&type=Code
|
Change https://go.dev/cl/354010 mentions this issue: |
Updates golang/go#48801 yyyy-dd-mm is a time format that isn't really used anywhere [1]. It is much more likely that the user intended to use yyyy-mm-dd instead and made a mistake. This happens quite often [2] because of the unusual way to handle time formatting and parsing in Go. Since the mistake is Go specific and happens so often a vet check will be useful. 1. https://stackoverflow.com/questions/2254014/are-there-locales-or-common-programs-that-use-yyyy-dd-mm-as-the-date-format 2. https://github.com/search?l=&p=1&q=%222006-02-01%22+language%3AGo&type=Code
Indeed, but they also don't have a vet check. |
Seems like this is going to happen: #52746 |
yyyy-dd-mm is a time format that isn't really used anywhere [1]. It is much more likely that the user intended to use yyyy-mm-dd instead and made a mistake. This happens quite often [2] because of the unusual way to handle time formatting and parsing in Go. Since the mistake is Go specific and happens so often a vet check will be useful. 1. https://stackoverflow.com/questions/2254014/are-there-locales-or-common-programs-that-use-yyyy-dd-mm-as-the-date-format 2. https://github.com/search?l=&p=1&q=%222006-02-01%22+language%3AGo&type=Code Updates golang/go#48801
yyyy-dd-mm is a time format that isn't really used anywhere [1]. It is much more likely that the user intended to use yyyy-mm-dd instead and made a mistake. This happens quite often [2] because of the unusual way to handle time formatting and parsing in Go. Since the mistake is Go specific and happens so often a vet check will be useful. 1. https://stackoverflow.com/questions/2254014/are-there-locales-or-common-programs-that-use-yyyy-dd-mm-as-the-date-format 2. https://github.com/search?l=&p=1&q=%222006-02-01%22+language%3AGo&type=Code Updates golang/go#48801
yyyy-dd-mm is a time format that isn't really used anywhere [1]. It is much more likely that the user intended to use yyyy-mm-dd instead and made a mistake. This happens quite often [2] because of the unusual way to handle time formatting and parsing in Go. Since the mistake is Go specific and happens so often a vet check will be useful. 1. https://stackoverflow.com/questions/2254014/are-there-locales-or-common-programs-that-use-yyyy-dd-mm-as-the-date-format 2. https://github.com/search?l=&p=1&q=%222006-02-01%22+language%3AGo&type=Code Updates golang/go#48801
yyyy-dd-mm is a time format that isn't really used anywhere [1]. It is much more likely that the user intended to use yyyy-mm-dd instead and made a mistake. This happens quite often [2] because of the unusual way to handle time formatting and parsing in Go. Since the mistake is Go specific and happens so often a vet check will be useful. 1. https://stackoverflow.com/questions/2254014/are-there-locales-or-common-programs-that-use-yyyy-dd-mm-as-the-date-format 2. https://github.com/search?l=&p=1&q=%222006-02-01%22+language%3AGo&type=Code Updates golang/go#48801
yyyy-dd-mm is a time format that isn't really used anywhere [1]. It is much more likely that the user intended to use yyyy-mm-dd instead and made a mistake. This happens quite often [2] because of the unusual way to handle time formatting and parsing in Go. Since the mistake is Go specific and happens so often a vet check will be useful. 1. https://stackoverflow.com/questions/2254014/are-there-locales-or-common-programs-that-use-yyyy-dd-mm-as-the-date-format 2. https://github.com/search?l=&p=1&q=%222006-02-01%22+language%3AGo&type=Code Updates golang/go#48801 Change-Id: I20960c93710766f20a7df90873bff960dea41b28 GitHub-Last-Rev: 496b991 GitHub-Pull-Request: #342 Reviewed-on: https://go-review.googlesource.com/c/tools/+/354010 gopls-CI: kokoro <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Tim King <[email protected]> Run-TryBot: Tim King <[email protected]> Reviewed-by: Robert Findley <[email protected]>
|
Should this be closed given https://go.dev/cl/354010 is merged? |
|
CL 354010 adds the |
|
Change https://go.dev/cl/450495 mentions this issue: |
yyyy-dd-mmis a time format that isn't really used anywhere [1]. It is much more likely that the user intended to useyyyy-mm-ddinstead and made a mistake. This happens quite often [2] because of the unusual way to handle time formatting and parsing in Go. Since the mistake is Go specific and happens so often a vet check will be useful.See: golang/tools#342
The text was updated successfully, but these errors were encountered: