Skip to content
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

time: RFC3339 format parsing is both too lax and too strict #20869

Closed
oschwald opened this issue Jun 30, 2017 · 4 comments
Closed

time: RFC3339 format parsing is both too lax and too strict #20869

oschwald opened this issue Jun 30, 2017 · 4 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@oschwald
Copy link

oschwald commented Jun 30, 2017

As of Go 1.8.3, the RFC3339 format has several inconsistencies with the actual RFC when parsing a string:

  1. One digit hours are incorrectly allowed, e.g., 2017-04-09T0:38:00.00Z. I assume this is because there is no stdZeroHour similar to stdZeroHour12 ("03").
  2. The format is case sensitive. The RFC says:
  NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this
 syntax may alternatively be lower case "t" or "z" respectively.

 This date/time format may be used in some environments or contexts
 that distinguish between the upper- and lower-case letters 'A'-'Z'
 and 'a'-'z' (e.g. XML).  Specifications that use this format in
 such environments MAY further limit the date/time syntax so that
 the letters 'T' and 'Z' used in the date/time syntax must always
 be upper case.  Applications that generate this format SHOULD use
 upper case letters.

Also, it does not parse leap seconds, which are explicitly allowed under the standard, but that seems more like an intentional design decision.

In reporting this, I am assuming the omission of RFC3339 from the comment:

RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting; when used with time.Parse they do not accept all the time formats permitted by the RFCs.

suggests that you should be able to parse all time formats permitted by it.

@oschwald oschwald changed the title RFC3339 format parsing is both too lax and too string RFC3339 format parsing is both too lax and too strict Jun 30, 2017
@ALTree ALTree changed the title RFC3339 format parsing is both too lax and too strict time: RFC3339 format parsing is both too lax and too strict Jun 30, 2017
@ALTree ALTree added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 30, 2017
@ALTree ALTree added this to the Go1.10 milestone Jul 18, 2017
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/74231 mentions this issue: time: document valid layouts are not valid Parse values

@kennygrant
Copy link
Contributor

See also #11128

gopherbot pushed a commit that referenced this issue Oct 31, 2017
For #9346 #22135 explicitly state under layout constants
that they are not valid time values for Parse. Also add
examples of parsing valid RFC3339 values and the layout
to the example for time.Parse.

Fix capitalisation of time.Parse and Time.Format.

For #20869 include RFC3339 in the list of layouts that do
not accept all the time formats allowed by RFCs (lowercase z).
This does not fully address #20869.

Fixes #9346
Fixes #22135

Change-Id: Ia4c13e5745de583db5ef7d5b1688d7768bc42c1b
Reviewed-on: https://go-review.googlesource.com/74231
Run-TryBot: Ian Lance Taylor <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Ian Lance Taylor <[email protected]>
@rsc
Copy link
Contributor

rsc commented Nov 22, 2017

Given that generators should generate T and Z, not t and z, I'm not particularly inclined to try to fix this.

@seankhliao
Copy link
Member

Duplicate of #54580

@seankhliao seankhliao marked this as a duplicate of #54580 Nov 15, 2022
@seankhliao seankhliao closed this as not planned Won't fix, can't repro, duplicate, stale Nov 15, 2022
@golang golang locked and limited conversation to collaborators Nov 15, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

7 participants