为什么无法解析所提供格式表示的时间?

huangapple go评论101阅读模式
英文:

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.

huangapple
  • 本文由 发表于 2015年9月16日 01:44:46
  • 转载请务必保留本文链接:https://go.coder-hub.com/32592458.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定