标签: timestamp-with-timezone

我有一个简单的移动应用程序,可以安排指定位置的人们之间的未来事件.这些事件可以是物理事件或虚拟事件,因此为事件指定的时间可能与事件的"位置"位于同一时区,也可能不在同一时区.例如,可以在当地时间上午10点在指定日期为伦敦的两个人安排实际会议.或者,可以在指定日期下午4点(在一个人的时区)为不同时区的两个人安排Skype呼叫,尽管事件的"位置"仅仅是"办公室",这意味着在不同时区的两个不同的地方.

我想知道以下设计适用于此应用程序:

1. 在客户端上,它要求用户输入本地日期和时间,并指定事件的本地时区.

2. 在服务器上,它将使用提供的时区的本地日期和时间转换为UTC时间戳,并仅存储此时间戳.

3. 当客户端检索这些详细信息时,它仅接收UTC时间戳并将其转换为与客户端当前时区相同的时区中的本地时间.客户端的当前时区由当前系统时区设置决定,我认为这是根据客户端的位置自动调整的(当然,假设客户端连接到移动网络).

我对这种设计的主要动机是:

1. UTC是一种绝对的通用时间标准,您可以从/向任何时区转换.

2. 用户只关心他们当前所在时区的本地日期和时间.

这是一个可行的设计吗？如果没有,具体情况会破坏应用程序或严重影响用户体验？批评欢迎.

我的头开始因为时间戳和时区问题而旋转。在我的应用程序中，所有时间戳都保存为 UTC。提交时区单独保存。

环境如下：

• 操作系统：旧金山 Digital Ocean Droplet 上的 CentOS
• 应用服务器：Apache Tomcat
• 后端：Java -> Hibernate -> Spring
• 数据库：PostgreSQL

我解决的第一个问题是 PostgreSQL 默认时区设置America/Eastern在旧金山的服务器上。所以我改用了 UTC，但这只是问题的一部分，我不能 100% 确定它做了什么。仅供参考，PostgreSQL 中的列是TIMESTAMP WITH TIME ZONE.

测试的本地化日期，即 MST 或 UTC-07：

• “2016-01-20 13:45:19.894 MST”

所有测试的插入中使用的 UTC 日期：

• “2016-01-20 20:45:19.894Z”

第一次测试：--------------------------------------------------------

通过快速 SQL 插入，将输入正确的日期。当我查询时，我得到本地化日期，因为我的本地系统将其与 MST 偏移 -7 小时。

查询后日期：

• “2016-01-20 13:45:19.894”

这确实是我本地插入的时间。

第二次测试：--------------------------------------------------------

这就是奇怪的地方。现在，我使用与 SQL 插入中相同的 UTC 时间戳通过应用程序输入日期。

现在看看我查询时会出现什么结果：

• “2016-01-20 18:45:19.0”

如果使用原始 SQL 插入，则日期减去 7 小时即可得到本地时间。如果我的本地计算机从原始 UTC 时间戳中减去 7，则应用程序返回的原始 UTC 时间戳将加上 7 小时，得出：

• “2016-01-21 01:45:19.0”

而不是我放进去的。呵呵。。。？

由于 …

我尝试使用时区格式将字符串解析为时间戳。

这是一个例子

"2016-02-18 16:13:07+09"

我想知道在python中将此字符串格式解析为时间戳格式。

我怎样才能做到这一点？

I have a simple table that store precipitation readings from online gauges. Here's the table definition:

    CREATE TABLE public.precip
    (
        gauge_id smallint,
        inches numeric(8, 2),
        reading_time timestamp with time zone
    )

    CREATE INDEX idx_precip3_id
        ON public.precip USING btree
        (gauge_id)

    CREATE INDEX idx_precip3_reading_time
        ON public.precip USING btree
        (reading_time)

CREATE INDEX idx_precip_last_five_days
    ON public.precip USING btree
    (reading_time)
    TABLESPACE pg_default    WHERE reading_time > '2017-02-26 00:00:00+00'::timestamp with time zone

It's grown quite large: about 38 million records that go back 18 months. Queries rarely …

我有一个值'2017-09-27T19：25：15.927-07：00'，有什么办法可以将其转换为时间戳吗？我使用Hive 1.1.0。

select unix_timestamp("2017-09-27T19:25:15.927-07:00", "yyyy-MM-ddTHH:mm:ss.SSSX") 但它抛出 Bad date/time conversion format

select unix_timestamp("2017-09-27T19:25:15.927-07:00", "yyyy-MM-ddTHH:mm:ss.SSSZZZ") 但它返回 NULL

我试图从中提取本地时间timestamp with time zone，但是由于我不熟悉这种数据类型，因此得到了意外的结果。

我期望22作为下面每一行的输出。

with my_data as(
   select to_timestamp_tz(ts, 'yyyy-mm-dd hh24:mi:ss tzh:tzm') as tsz
     from (select '2017-12-07 22:23:24 +' || lpad(level, 2, '0') || ':00' as ts  
             from dual connect by level <= 10
          )       
)
select dbtimezone
      ,sessiontimezone
      ,tsz
      ,extract(hour from tsz)
  from my_data;

为什么会发生这种情况，我该怎么做才能从带有时区的时间戳中提取本地时间？

我试图了解Postgre中的时间戳和时区。我想我明白了，直到我写这篇文章为止。
专注于“在时区之间转换”部分。它有两个例子。

（将默认时区配置考虑为UTC。）

例子1

db=# SELECT timezone('US/Pacific', '2016-01-01 00:00'); outputs 2015-12-31 16:00:00

根据本文和我的理解，由于该函数的'2016-01-01 00:00'一部分timezone只是一个字符串，因此将其静默转换为默认的UTC。因此，'2016-01-01 00:00' UTC然后将其转换US/Pacific为timezone函数所要求的，即2015-12-31 16:00:00。

例子2

db=# SELECT timezone('US/Pacific', '2016-01-01 00:00'::timestamp); outputs 2016-01-01 08:00:00+00

不好意思，我不明白为什么，那里的解释也无济于事。好的，函数的'2016-01-01 00:00'::timestamp一部分timezone不再是字符串，而是实际的时间戳。在什么时区？如果是UTC，则输出必须与示例1相同。因此，它将自动转换为US/Pacific？。那么输出是UTC吗？但为什么？我要求的 不是US/Pacific我timezone的UTC。

请说明timezone何时获取时间戳并被要求转换时间戳时的行为。谢谢。

I\xe2\x80\x99 已被调整为将过去的日期作为 UTC 存储在数据库中，因为这实际上是事件发生的时间。对于未来的日期，我会将其与特定时区一起存储，以避免诸如闰秒或时区规则更改之类的更改。

Postgres 有timestamp with timezone，但在幕后，它将其存储为 UTC，从而推断指定的时区是 UTC 的偏移量。如果时区规则发生更改，则不会反映在该列中。

在这种情况下有什么建议？

我使用 Azure 数据资源管理器来存储温度传感器值。时间戳采用 UTC 时间。我想在过去 7 天内按天汇总这些值。尽管如此，我想使用这些值的来源地本地时间，并按本地时间的时间戳进行聚合（例如，午夜将在 00:00+2h 和 22:00UTC）。如何使用 ADX 中的 Kusto 查询语言执行此操作？

我在两个不同的数据库中运行了相同的语句：我的 Local DB 和Oracle Live SQL。

CREATE TABLE test(
    timestamp TIMESTAMP DEFAULT SYSDATE,
    timestamp_tmz TIMESTAMP WITH TIME ZONE DEFAULT SYSDATE,
    timestamp_local_tmz TIMESTAMP WITH LOCAL TIME ZONE DEFAULT SYSDATE
);

INSERT INTO test VALUES (DEFAULT, DEFAULT, DEFAULT);

SELECT * FROM test;

（所有语句大约在同一时间执行 - 欧洲中部时间上午 09:35）

我的本地数据库的结果：

TIMESTAMP: 10-JAN-23 09.35.32.000000000 AM
TIMESTAMP WITH TIME ZONE: 10-JAN-23 09.35.32.000000000 AM EUROPE/BERLIN
TIMESTAMP WITH LOCAL TIME ZONE: 10-JAN-23 09.35.32.000000000 AM

Oracle Live 的结果：

TIMESTAMP: 10-JAN-23 08.35.44.000000 AM 
TIMESTAMP WITH TIME ZONE: 10-JAN-23 08.35.44.000000 …