猿问

为什么不能解析提供的格式表示的时间?

考虑这个例子:


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.RFC3339 作为布局字符串时,为什么 time.Parse() 不能处理时区信息?


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


更新: JimB 的回答让我阅读了 RFC3339,我发现这些示例进一步阐明了:


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


1985-04-12T23:20:50.52Z


这表示 UTC 时间 1985 年 4 月 12 日第 23 小时后的 20 分 50.52 秒。


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


这表示 1996 年 12 月 19 日第 16 小时之后的 39 分 57 秒,与 UTC(太平洋标准时间)的偏移量为 -08:00。请注意,这等效1996-12-20T00:39:57Z 于 UTC。


至尊宝的传说
浏览 175回答 2
2回答

哆啦的时光机

该time.RFC3339格式是在格式字符串本身是无效的时间的情况下。时间字符串中不能有 aZ 和偏移量,但格式字符串两者都有,因为规范可以包含任一类型的时区规范。这两个都是有效的 RFC3339 次:"2015-09-15T14:00:12-00:00""2015-09-15T14:00:13Z"并且时间包需要能够使用相同的 RFC3339 格式字符串解析它们。

狐的传说

如前所述,2006-01-02T15:04:05Z07:00是无效的IETF RFC-3339时间格式。这是一个解释。您不能同时拥有 Z 和偏移量的原因是它们都是表示时间偏移量的方式。Z相当于+00:00指示零小时/分钟偏移量,或无偏移量。您不能在同一时间表示中同时说+00:00偏移量和+07:00偏移量。以下是ZRFC-3339 第 2 节中的定义:https://www.rfc-editor.org/rfc/rfc3339#section-2Z  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:00which 表示具有未知偏移量的已知 UTC 时间,如 RFC-3339 第 4.3 节所述:https://www.rfc-editor.org/rfc/rfc3339#section-4.34.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.
随时随地看视频慕课网APP

相关分类

Go
我要回答