Question

考虑这个例子：

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（）作为值处理布局？这里缺少什么？

更新：切断时区值（但不是＆＃39; Z＆＃39;从区域划分时间）修复了它：

fmt.Println(time.Parse(time.RFC3339, "2015-09-15T11:50:00Z"))

为什么在使用time.RFC3339作为布局字符串时，time.Parse（）会处理时区信息？

http://play.golang.org/p/p3fHfJNHVK

更新：JimB的回答让我读了RFC3339，我发现这些例子进一步澄清了：

以下是互联网日期/时间格式的一些示例。

1985-04-12T23:20:50.52Z

这表示在第23个小时之后的20分钟和50.52秒   1985年4月12日，UTC。

1996-12-19T16:39:57-08:00

这代表了第16个小时后39分57秒   1996年12月19日，UTC（太平洋地区）偏离-08：00   标准时间）。请注意，这相当于1996-12-20T00:39:57Z   在UTC。

Answer 1

time.RFC3339格式是格式字符串本身不是有效时间的情况。时间字符串中不能有Z 和偏移量，但格式字符串包含两者，因为规范可以包含任何类型的时区规范。

这两个都是有效的RFC3339次：

"2015-09-15T14:00:12-00:00"
"2015-09-15T14:00:13Z"

时间包需要能够使用相同的RFC3339格式字符串解析它们。

Answer 2

如上所述，2006-01-02T15:04:05Z07:00是无效的IETF RFC-3339时间格式。这是一个解释。

你不能同时拥有Z和偏移的原因是它们都是表示时间偏移的两种方式。 Z相当于+00:00，表示零小时/分钟偏移，或没有偏移。您不能在同一时间表示中同时说明+00:00偏移量和+07:00偏移量。

以下是RFC-3339第2节中的Z定义：

https://tools.ietf.org/html/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".

值得注意的是，虽然Z等同于+00:00，但它们与-00:00不同，后者表示已知的具有未知偏移的UTC时间，如RFC-3339第4.3节中所述：

https://tools.ietf.org/html/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.

为什么不能解析所提供格式所代表的时间？

2 个答案: