英文:
Why can't go parse the time represented by the provided formats?
问题
考虑以下示例:
package main
import (
"fmt"
"time"
)
func main() {
fmt.Println(time.Parse(time.RFC3339, time.RFC3339))
}
输出结果为:
0001-01-01 00:00:00 +0000 UTC parsing time "2006-01-02T15:04:05Z07:00": extra text: 07:00
为什么time.Parse()
不能处理布局作为值的情况?这里缺少了什么?
更新: 去掉时区值(但保留将时间与时区分隔的 'Z')可以修复这个问题:
fmt.Println(time.Parse(time.RFC3339, "2015-09-15T11:50:00Z"))
为什么time.Parse()
在使用time.RFC3339
作为布局字符串时不能处理时区信息?
http://play.golang.org/p/p3fHfJNHVK
更新: JimB的答案让我阅读了RFC3339,并找到了以下进一步澄清的示例:
以下是一些互联网日期/时间格式的示例。
1985-04-12T23:20:50.52Z
这表示在1985年4月12日的第23小时20分50.52秒之后的20分钟。在UTC时间中。
1996-12-19T16:39:57-08:00
这表示在1996年12月19日的第16小时39分57秒之后的39分钟。与UTC时间相比,偏移量为-08:00(太平洋标准时间)。请注意,这等同于UTC时间中的
1996-12-20T00:39:57Z
。
英文:
Consider this example:
package main
import (
"fmt"
"time"
)
func main() {
fmt.Println(time.Parse(time.RFC3339, time.RFC3339))
}
The output is:
0001-01-01 00:00:00 +0000 UTC parsing time "2006-01-02T15:04:05Z07:00": extra text: 07:00
Why can't time.Parse() handle a layout as a value? What's missing here?
UPDATE: Cutting off the time zone value (but not the 'Z' delimiting the time from the zone) fixes it:
fmt.Println(time.Parse(time.RFC3339, "2015-09-15T11:50:00Z"))
Why can't time.Parse() handle time zone info when using time.RFC3339 as the layout string?
http://play.golang.org/p/p3fHfJNHVK
UPDATE: JimB's answer led me to read from RFC3339 and I found these examples that clarify further:
Here are some examples of Internet date/time format.
> 1985-04-12T23:20:50.52Z
>
> This represents 20 minutes and 50.52 seconds after the 23rd hour of
> April 12th, 1985 in UTC.
>
> 1996-12-19T16:39:57-08:00
>
> This represents 39 minutes and 57 seconds after the 16th hour of
> December 19th, 1996 with an offset of -08:00 from UTC (Pacific
> Standard Time). Note that this is equivalent to 1996-12-20T00:39:57Z
> in UTC.
答案1
得分: 35
time.RFC3339
格式是一种特殊情况,其中格式字符串本身不是一个有效的时间。时间字符串中不能同时包含Z
和偏移量,但是格式字符串中同时包含了两者,因为规范可以包含任一类型的时区指定。
以下两个时间都是有效的RFC3339时间:
"2015-09-15T14:00:12-00:00"
"2015-09-15T14:00:13Z"
时间包需要能够使用相同的RFC3339格式字符串解析它们。
英文:
The time.RFC3339
format is a case where the format string itself isn't a valid time. You can't have a Z
and an offset in the time string, but the format string has both because the spec can contain either type of timezone specification.
Both of these are valid RFC3339 times:
"2015-09-15T14:00:12-00:00"
"2015-09-15T14:00:13Z"
And the time package needs to be able to parse them both using the same RFC3339 format string.
答案2
得分: 8
如前所述,2006-01-02T15:04:05Z07:00
是一个无效的IETF RFC-3339时间格式。下面是一个解释。
你不能同时使用Z和偏移量,因为它们都是表示时间偏移的方式。Z
等同于+00:00
,表示零小时/分钟的偏移量,或者没有偏移量。你不能在同一个时间表示中同时使用+00:00
偏移量和+07:00
偏移量。
以下是RFC-3339第2节中关于Z
的定义:
https://www.rfc-editor.org/rfc/rfc3339#section-2
Z 一个后缀,当应用于时间时,表示UTC偏移量为00:00;通常从字母“Z”的ICAO音标表示中称为“Zulu”。
需要注意的是,虽然Z
等同于+00:00
,但它们与表示已知UTC时间但未知偏移量的-00:00
不同,如RFC-3339第4.3节所述:
https://www.rfc-editor.org/rfc/rfc3339#section-4.3
4.3. 未知本地偏移约定
如果已知UTC时间,但未知到本地时间的偏移量,可以使用“-00:00”表示偏移量。这在语义上与“Z”或“+00:00”的偏移量不同,后者意味着UTC是指定时间的首选参考点。RFC2822 [IMAIL-UPDATE]中描述了一种类似的电子邮件约定。
英文:
As noted, 2006-01-02T15:04:05Z07:00
is an invalid IETF RFC-3339 time format. Here's an explanation.
The reason you cannot have both Z and an offset is that they are both ways to represent a time offset. Z
is equivalent to +00:00
indicating a zero hour/minute offset, or no offset. You cannot say both +00:00
offset and +07:00
offset in the same time representation.
The following is the Z
definition in the RFC-3339 Section 2:
https://www.rfc-editor.org/rfc/rfc3339#section-2
Z A suffix which, when applied to a time, denotes a UTC
offset of 00:00; often spoken "Zulu" from the ICAO
phonetic alphabet representation of the letter "Z".
Of note, while Z
is equivalent to +00:00
, they are both different from -00:00
which indicates known UTC time with an unknown offset, as described in RFC-3339 Section 4.3:
https://www.rfc-editor.org/rfc/rfc3339#section-4.3
4.3. Unknown Local Offset Convention
If the time in UTC is known, but the offset to local time is unknown,
this can be represented with an offset of "-00:00". This differs
semantically from an offset of "Z" or "+00:00", which imply that UTC
is the preferred reference point for the specified time. RFC2822
[IMAIL-UPDATE] describes a similar convention for email.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论