Questions tagged «timestamp»

有关时间戳数据类型和/或记录特定时间点的问题。

2
如何从PostgreSQL获取当前的unix时间戳?
Unix时间戳是自1970年1月1日UTC午夜以来的秒数。 如何从PostgreSQL获取正确的Unix时间戳? 与currenttimestamp.com和timestamp.1e5b.de进行比较时,我没有从PostgreSQL获得预期的时间: 这将返回正确的时间戳: SELECT extract(epoch from now()); 虽然这不是: SELECT extract(epoch from now() at time zone 'utc'); 我住在时区UTC +02。从PostgreSQL获取当前unix时间戳的正确方法是什么? 这将返回正确的时间和时区: SELECT now(); now ------------------------------- 2011-05-18 10:34:10.820464+02 另一个比较: select now(), extract(epoch from now()), extract(epoch from now() at time zone 'utc'); now | date_part | date_part -------------------------------+------------------+------------------ 2011-05-18 10:38:16.439332+02 | 1305707896.43933 | …

2
now()和current_timestamp之间的区别
在PostgreSQL中,我使用now()and current_timestamp函数,但没有区别: # SELECT now(), current_timestamp; now | now --------------------------------+-------------------------------- 04/20/2014 19:44:27.215557 EDT | 04/20/2014 19:44:27.215557 EDT (1 row) 我想念什么吗?

4
MySQL将UTC时间设置为默认时间戳
如何设置默认值为当前UTC时间的时间戳列? MySQL将UTC_TIMESTAMP()函数用于UTC时间戳: mysql> SELECT UTC_TIMESTAMP(); +---------------------+ | UTC_TIMESTAMP() | +---------------------+ | 2012-07-01 11:36:35 | +---------------------+ 1 row in set (0.00 sec) 所以我尝试了: CREATE TABLE `blah` ( `creation_time` TIMESTAMP DEFAULT UTC_TIMESTAMP, ... 和其他变体一样UTC_TIMESTAMP(),但没有成功。

2
如何仅以毫秒为单位从PostgreSQL获取时间戳列?
我timestamp without time zone default now()在PostgreSQL数据库中有一列“创建”的类型。 如果我选择“ colums”,则默认情况下它的格式很好看: SELECT created FROM mytable; created --------------------------- 2011-05-17 10:40:28.876944 但是我只想以毫秒为单位获取时间戳(以Long为单位)。像这样: 从mytable中选择myformat(创建); created ----------------- 2432432343876944 我怎样才能在几毫秒内从PostgreSQL获取时间戳列? 对杰克的回应: 我确实得到了与您(-3600)相同的区别,但是如果我使用的话,timestamp with time zone我会看到“错误”或区别是因为'1970-01-01'获得了时区+01。 create table my_table_2(created timestamp with time zone); CREATE TABLE insert into my_table_2 (created) values (now()), ('1970-01-01'); INSERT 0 2 select created, extract(epoch from …

2
如何最好地在PostgreSQL中存储时间戳?
我正在研究PostgreSQL数据库设计,我想知道如何最好地存储时间戳。 假设条件 不同时区的用户将数据库用于所有CRUD功能。 我看了两个选项: timestamp NOT NULL DEFAULT (now() AT TIME ZONE 'UTC') bigint NOT NULL DEFAULT 因为timestamp我会发送一个字符串,该字符串代表INSERT时刻的确切(UTC)时间戳。 因为bigint我会以数字格式存储完全相同的内容。(时区问题是在将毫秒移交给服务器之前处理的,因此始终在UTC中使用毫秒。) 存储a的一个主要优点bigint是可以更容易存储和检索,因为传递正确格式的时间戳比简单的数字(自Unix Epoc以来的毫秒数)要复杂得多。 我的问题是,哪种方法可以进行最灵活的设计,以及每种方法的陷阱是什么?


1
如何在没有timezome的情况下将unix时间转换为PostgreSQL的Timstamp?
我有一个在其时区设置为印度时区(即UTC +5:30)的服务器上运行的PostgreSQL数据库。 我在这样创建的表中有一些数据: CREATE TABLE "CLOUDDATA" ( "CD_Tm_Obs" timestamp without time zone, "CD_Avg_Cloud" double precision ) 我想查询数据并获取特定时间的值。我的输入将是Unix时间戳(即1970年1月1日的秒数) 我发现将unix时间转换为时间戳的唯一方法是: select to_timestamp(TRUNC(CAST(1395036000 AS bigint)))。但这会创建带有时区的时间戳。我的数据在中timestamp without time zone,因此没有任何结果。 如何在没有timezome的情况下将unix时间转换为PostgreSQL的Timstamp?

1
为什么时区在Postgres的0001年有如此疯狂的UTC偏移量?
在Postgres 9.5中,我很惊讶地看到下面的年份在尝试年份0001(没有年份0 0000)时看到。 偏移量-07:52:58? 一些示例代码。请注意,我混合使用TIMESTAMP WITH TIME ZONE和TIMESTAMP WITHOUT TIME ZONE,因此请仔细阅读。 SET TIME ZONE 'America/Los_Angeles' ; SELECT (TIMESTAMP WITH TIME ZONE '2015-01-01 00:00:00.0', TIMESTAMP WITH TIME ZONE '0001-01-01 00:00:00.0Z', TIMESTAMP WITHOUT TIME ZONE '0001-01-01 00:00:00.0Z') ; ("2015-01-01 00:00:00-08","0001-12-31 16:07:02-07:52:58 BC","0001-01-01 00:00:00") 我对第二个值感到惊讶:0001-12-31 16:07:02-07:52:58 BC。我知道我们必须向后退8 America/Los_Angeles个小时,比UTC 落后8个小时,但要相差-08:00。但不是-08:00偏移量是-07:52:58。为什么? UTC下没问题 在UTC下输入数据时没有这种问题。 SET TIME …

3
区域名称PostgreSQL错误的“ AT TIME ZONE”?
我在回答这个stackoverflow问题,发现奇怪的结果: select * from pg_timezone_names where name = 'Europe/Berlin' ; name | abbrev | utc_offset | is_dst ---------------+--------+------------+-------- Europe/Berlin | CET | 01:00:00 | f 和下一个查询 select id, timestampwithtimezone, timestampwithtimezone at time zone 'Europe/Berlin' as berlin, timestampwithtimezone at time zone 'CET' as cet from data ; id | timestampwithtimezone | …


3
在数据库中存储时间(以毫秒为单位)
关于在数据库中存储“时间”的一个简单问题。我正在记录用户运行时间,其格式为00:00:00:00(小时,分钟,秒,毫秒)。 我本来打算将其存储为,TIME但是后来我意识到MySQL不支持这种类型的毫秒。 我将存储从用户秒表获取的实际时间,而不是他们运行并完成的时间(这将在插入之前进行计算)。 最好使用哪种字段类型?我在想double或者float,但是我不确定是否行得通?

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.