我负责编写一个应用程序来处理大量的客户和商业智能信息。此信息涉及各种业务和指标（如收入、其网络平台等）的记录。出于报告目的，已决定现在必须对数据加盖时间戳，以便我们可以构建诸如“Foo Inc. 的收入增加”之类的报告当他们在 2010 年转向数字电视时，增长了 200%。”
或者类似的东西。我们真的不对付那些客户是远远落后于时代。
就目前而言，数据存储在 MongoDB 中，其模式（或缺乏模式）准确地表示了它的显示方式。一个文档有一个名称，可能是用于地址信息或与操作相关的统计信息等的嵌入式文档。我不知何故需要添加时间戳或版本控制的概念。最明显的建模方法是这样的：
key: [{ value: "bar", time: "2012" }, { value: "baz", time: "2011" }]
每个属性都有时间戳。显然，这打破了模式，并增加了维护问题。我还尝试过使用约定（命名属性键，如“Foo (2012-09-31)”，并保留带有时间戳的整个集合的副本。
显然，这是一个非常重要的实现功能，我想知道实现它的最佳方法是什么。在 MongoDB 中为数据添加时间戳的最有效和性能友好的方法是什么？
编辑：是的，我正在考虑版本控制，尽管新数据集很可能会成批出现，而不是经常出现（例如，每个季度）。这就是我考虑为每个集合使用单独的集合并为每个集合添加时间戳的原因，因为数据很多而且相距甚远，但我很想知道是否有更好、更易于维护的方法。
查询是这样的：
$today = $date->getTimestamp();
SELECT t.*, u.screen_name, u.profile_image_url
FROM table AS t
LEFT JOIN users AS u
ON t.user_id=u.id_str
WHERE UNIX_TIMESTAMP(t.created_at) > {$today}
ORDER BY id DESC
LIMIT 12;
考虑到一个指定的表bananas
和一个timestamp without time zone名为列end_time
和 一些 psql客户有set timezone to 'UTC'
和 其他 psql客户端有set timezone to 'US/Eastern'
和服务器配置有timezone = 'UTC'中postgresql.conf
如何编写支票约束bananas.end_time以确保end_time始终是一天的结束，定义为“美国/东部”一天的第 23 小时 59 分 59 秒？
我试过：
alter table bananas
add constraint ck_end_time_is_end_of_day
check (
23 = date_part('hour', end_time at time zone 'UTC' at time zone 'US/Eastern')
and 59 = date_part('minute', end_time at time zone 'UTC' at time zone …我有时间戳（存储为 BIGINT）格式，我无法变成人类可读的格式：
1462975819250
它指向 2016 年 5 月 11 日的日期。但是函数 to_timestamp() 将其转换为：
48329-11-10 13:00:49.999872+01
我想创建一个可以显示这些值的 VIEW，不知道要使用什么函数。
该字段由 Java 程序（我认为是 EclipseLink）编写。我没有程序的源代码。
我有一个date具有以下值格式的类型列：（YYYY-MM-DD例如。2018-08-03）。我想获得与日期等效的 unix 时间戳，但没有时区。
Fe 日期2018-08-03应该相等1533254400（从这里计算）。
我试过了，to_timestamp(my_date_column, 'YYYY-MM-DD')但它返回 error function to_timestamp(date, unknown) does not exist。我尝试::timestamp...在函数调用结束时添加不同的变体，但无济于事。
目前我在应用程序层进行时间戳转换，但我想将该工作专用于数据库。
ERROR: timestamp out of range: "1.52701e+15"当我尝试将存储为 bigint 的纪元转换为时间戳（值取自真实数据库表）时，我得到了：
select to_timestamp(1527012834506374);
ERROR: timestamp out of range: "1.52701e+15"
其他转换方法也不起作用：
select 1527012834506374::abstime::timestamp;
ERROR: cannot cast type bigint to abstime
select 1527012834506374::integer::abstime::timestamp;
ERROR: integer out of range
这是一个有效的时代；https://www.epochconverter.com/告诉我 1527012834506374 相当于 2018-05-22 06:13:54.506 UTC
如何在 Postgres 中使用 SQL 进行转换？
我在 PostgreSQL 中创建了一个小型数据库来管理我的论文数据。我刚刚开始使用 Postgres，所以这可能是一个新手问题。我在几个表中添加了一列，该列应该保存某个字段的最后更新。其中一个表如下所示（此处相关的列是lastupdate：
-- Drop table
-- DROP TABLE public.finds;
CREATE TABLE public.finds (
id bigserial NOT NULL,
id_investigations int8 NOT NULL,
quote_short varchar NULL,
"group" varchar NULL,
"type" varchar NULL,
subtype varchar NULL,
description varchar NULL,
"number" int4 NULL,
certainty bool NULL,
note varchar NULL,
checked bool NULL,
lastupdate timestamptz NULL,
CONSTRAINT finds_check_group CHECK ((("group")::text = ANY ((ARRAY['Keramik'::character varying, 'Waffe'::character varying, 'Werkzeug'::character varying, 'Schmuck'::character varying])::text[]))),
CONSTRAINT finds_pkey PRIMARY KEY (id),
CONSTRAINT id_investigations FOREIGN KEY (id_investigations) REFERENCES …看起来 postgres 将字符串'now()'视为对函数的调用now()。
为什么 postgres 允许这样做？
select 'now'::timestamp;
或这个？
select 'now()'::timestamp;
甚至这个？
select ' ( ( ))) now)('::timestamp;
它不会对其他函数（例如clock_timestamp().
我正在将 Web 应用程序从 SqlServer 迁移到 PostgreSQL，并且我正在尝试找出要替换的类型datetime2。
一般的建议似乎是总是使用timestamptz，以及从不使用timestamp。给出的原因往往是时间戳和timestamptz存储相同（因此没有性能损失）并timestamptz自动转换为连接的时区。在 Rails 和 PostgreSQL 中完全忽略时区 | 堆栈溢出
不幸的是，我的旧版 .NET 代码库与日期时间非常不一致，我们通常以 UTC 进行渲染，而不管用户时区如何。最近的代码一直在使用 NodaTime 及其Instant类，但我们很少需要处理时间并且仅显示日期已经“足够接近”。然而，我对正确使用 NodaTime 的理解是尽可能晚地将 转换Instant为，而不是在数据库中。LocalDateTime
除此之外，我不完全确定 Postgres 如何知道“当前用户”的正确时区。我知道您可以专门将时区设置为会话参数SET TIME ZONE 'UTC';，您是否希望为每个连接执行此操作以适合“当前用户”？如果是这样，每当从连接池检索连接时都会重置它吗？我还看到 Npgsql 能够为连接字符串设置时区，如果是针对每个用户，这可能是不合适的？
所有这些使我认为最好的选择是用于timestamp所有日期时间，并使用应用程序逻辑转换为本地日期时间。我想另一个选择是用于timestamptz所有日期时间，强制连接在连接字符串中使用 UTC，并使用应用程序逻辑转换为本地日期时间。但是我担心 Postgres 会在 UTC 和 UTC 之间进行无操作转换时执行额外的工作。
TLDR：timestamptz如果应用程序始终插入/读取 UTC 并转换为本地日期时间本身，这仍然是首选吗？
timestamp with time zone对比timestamp without time zone：
我知道这timestamptz与在数据库中保存值时添加的时间戳无时区+（时区差）相同。也就是说，在数据库中，当存储时，它们都是无法区分的。
比如说，我决定只使用timestamp without time zone，即使是在推荐的情况下timestamp with time zone。我网站的用户可以记住，我和他们将始终使用 UTC 进行操作，即使我们碰巧处于不同的时区，效果会timestamp without time zone很好且没有缺陷吗？