我应该如何在 Postgres 中存储 Go 的 time.Location ？

你在学习Golang相关的知识吗？本文《我应该如何在 Postgres 中存储 Go 的 time.Location ？》，主要介绍的内容就涉及到，如果你想提升自己的开发能力，就不要错过这篇文章，大家要知道编程理论基础和实战操作都是不可或缺的哦！

在 postgres 中，我存储用户提供给我的数据：

column   |           type           | collation | nullable | default
------------+--------------------------+-----------+----------+---------
 id         | uuid                     |           | not null |
 value      | numeric                  |           |          |
 date       | timestamp with time zone |           |          |

现在我需要维护生成数据的原始时区。带有 timezone 的 timestamp 已标准化为数据库的时区，并且原始时区丢失，因此我必须手动将 date 从标准化时区恢复回来，然后再将其返回给用户。

大多数解决方案建议在表中添加额外的列，并将原始时区信息与时间戳一起存储：

Column   |           Type           | Collation | Nullable | Default
------------+--------------------------+-----------+----------+---------
 id         | uuid                     |           | not null |
 value      | numeric                  |           |          |
 date       | timestamp with time zone |           |          |
 tz         | text                     |           |          |

鉴于我使用的是 go，我应该从 time.time 中提取哪些信息来存储在 tz 中以获得最精确和无缝的恢复？

date.location().string() 似乎不正确，因为它可能返回相对值 local。

我应该如何将 tz 中的信息恢复到 time.time 中？

time.loadlocation(tz) 的结果是否足够好？

解决方案

保存后，我将使用 Time.Zone() 获取区域名称和偏移量：

func (t time) zone() (name string, offset int)

那么从数据库查询这样的时间戳时，可以使用time.FixedZone()构造一个time.Location：

func fixedzone(name string, offset int) *location

并使用 Time.In() 切换到此位置。

请注意！这将为您恢复一个“看似”在同一时区的时间戳，但如果您需要对其进行操作（例如向其添加天数），则结果可能不一样。原因是因为 time.fixedzone() 返回一个具有固定偏移量的时区，例如，它不知道有关 daylight savings 的任何信息，而您保存的原始时间戳可能有一个 time.location ，它确实知道这些事情。

以下是此类偏差的示例。 3 月有夏令时，因此我们将使用指向 3 月 1 日的时间戳，并为其添加 1 个月，这会导致时间戳位于夏令时之后。

cet, err := time.loadlocation("cet")
if err != nil {
    panic(err)
}

t11 := time.date(2019, time.march, 1, 12, 0, 0, 0, cet)
t12 := t11.adddate(0, 1, 0)
fmt.println(t11, t12)

name, offset := t11.zone()
cet2 := time.fixedzone(name, offset)
t21 := t11.utc().in(cet2)
t22 := t21.adddate(0, 1, 0)
fmt.println(t21, t22)

now := time.date(2019, time.april, 2, 0, 0, 0, 0, time.utc)
fmt.println("time since t11:", now.sub(t11))
fmt.println("time since t21:", now.sub(t21))
fmt.println("time since t12:", now.sub(t12))
fmt.println("time since t22:", now.sub(t22))

这将输出（在 Go Playground 上尝试）：

2019-03-01 12:00:00 +0100 cet 2019-04-01 12:00:00 +0200 cest
2019-03-01 12:00:00 +0100 cet 2019-04-01 12:00:00 +0100 cet
time since t11: 757h0m0s
time since t21: 757h0m0s
time since t12: 14h0m0s
time since t22: 13h0m0s

如您所见，添加 1 个月后的输出时间是相同的，但区域偏移量不同，因此它们在时间上指定了不同的时刻（这可以通过显示与任意时间的时间差来证明） ）。原始时间戳有 2 小时偏移，因为它知道我们跳过的 1 个月内发生的夏令时，而“恢复”时间戳的区域不知道这一点，因此结果具有相同的 1 小时偏移。在添加后的时间戳中，甚至区域名称在现实生活中也发生了变化：从 cet 到 cest，并且恢复的时间戳的区域也不知道这一点。

更浪费，并且仍然容易出现错误，但仍然有效的解决方案是将原始时间戳以 iso 8601 格式存储，例如 2019-05-2t17:24:37+01:00 在单独的列 datetext 中：

Column   |           Type           | Collation | Nullable | Default
------------+--------------------------+-----------+----------+---------
 id         | uuid                     |           | not null |
 value      | numeric                  |           |          |
 date       | timestamp with time zone |           |          |
 datetext   | text                     |           |          |

然后使用 date 查询本机时间戳列的强度，并返回给用户 datetext，这是最初发送的确切值。

今天关于《我应该如何在 Postgres 中存储 Go 的 time.Location ？》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！