考虑这个例子:
package main
import (
"fmt"
"time"
)
func main() {
fmt.Println(time.Parse(time.RFC3339, time.RFC3339))
}
Run Code Online (Sandbox Code Playgroud)
输出是:
0001-01-01 00:00:00 +0000 UTC parsing time "2006-01-02T15:04:05Z07:00": extra text: 07:00
Run Code Online (Sandbox Code Playgroud)
为什么time.Parse()不能将布局作为值处理?这里缺少什么?
更新:切断时区值(但不是从区域划分时间的'Z')修复它:
fmt.Println(time.Parse(time.RFC3339, "2015-09-15T11:50:00Z"))
Run Code Online (Sandbox Code Playgroud)
为什么time.Parse()在使用time.RFC3339作为布局字符串时不能处理时区信息?
http://play.golang.org/p/p3fHfJNHVK
更新: JimB的回答让我从RFC3339读取,我发现这些例子进一步澄清:
以下是Internet日期/时间格式的一些示例.
1985-04-12T23:20:50.52Z这代表1985年4月12日23日在UTC后的20分50秒.
1996-12-19T16:39:57-08:00这代表1996年12月19日16小时后39分57秒,与UTC(太平洋标准时间)相差-08:00.请注意,这相当于
1996-12-20T00:39:57ZUTC.
Jim*_*imB 18
该time.RFC3339格式是在格式字符串本身是无效的时间的情况下.时间字符串中不能包含a Z 和偏移量,但格式字符串具有两者,因为规范可以包含任何类型的时区规范.
这两个都是有效的RFC3339次:
"2015-09-15T14:00:12-00:00"
"2015-09-15T14:00:13Z"
Run Code Online (Sandbox Code Playgroud)
时间包需要能够使用相同的RFC3339格式字符串解析它们.
如前所述,2006-01-02T15:04:05Z07:00是无效的IETF RFC-3339时间格式。这是一个解释。
您不能同时拥有 Z 和偏移量的原因是它们都是表示时间偏移量的方式。Z相当于+00:00指示零小时/分钟偏移量,或无偏移量。您不能在同一时间表示中同时说+00:00偏移量和+07:00偏移量。
以下是ZRFC-3339 第 2 节中的定义:
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".
Run Code Online (Sandbox Code Playgroud)
值得注意的是,虽然Z等价于+00:00,但它们都不同于-00:00which 表示具有未知偏移量的已知 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.
Run Code Online (Sandbox Code Playgroud)