如何在数据库中存储UTC时间？ (数据库中存储utc时间格式)
在现代计算机科技的发展中，时间数据的处理越来越重要。在数据库中，时间戳是一个非常常见的数据类型，它可以表示一个特定事件发生的的时间。
UTC时间(协调世界时)是一种标准的时间格式，它与世界上每个地方的时间相同。这意味着，你可以在用UTC时间做基准的同时，在全球访问同样的时间数据。如果您想在数据库中存储这个标准时间格式，您需要考虑几个关键点。
需要明确UTC时间的格式。UTC时间以0时区的时间格式为基准，格式为：“YYYY-MM-DDThh:mm:ss.sssZ”。其中，“T”代表时间部分的分隔符，“Z”代表时间按照UTC时间进行序列化。需注意，日期和时间之间分隔符可以替换为空格，这不会改变时间的值。
需要确保数据库中存储的UTC时间是正确的。在存储UTC时间时，需要将其转换为UTC时间戳。UTC时间戳在Java语言中是使用Long类型进行存储的。如果您使用其他编程语言或框架，请查阅相关文档进行确认。在转换之前，应该先检查该时间是否已经是UTC时间戳，如果不是，则首先要将其转换为UTC时间戳。
如何在常见的数据库中存储UTC时间？
MYSQL数据库
在MYSQL中存储UTC时间戳，需要将其存储为整数类型，例如使用bigint类型。以下是一个示例创建表的语句：
CREATE TABLE `example_table` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`event_time` bigint(20) unsigned NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900__ci;
在INSERT语句中插入时间，需要将其转换为UTC时间戳。
INSERT INTO `example_table` (`event_time`) VALUES (UNIX_TIMESTAMP(UTC_TIMESTAMP()));
在查询中，可以使用FROM_UNIXTIME函数将时间戳转换为日期格式。
SELECT FROM_UNIXTIME(`event_time`) FROM `example_table`;
在MYSQL中，DATE_ADD函数可以用于在SELECT查询中将时间戳转换为UTC时间。
SELECT DATE_ADD(‘1970-01-01 00:00:00’, INTERVAL `event_timestamp` SECOND) FROM `example_table`;
PostgreSQL数据库
在PostgreSQL中，可以使用TIMESTAMP WITH TIME ZONE数据类型来存储UTC时间。以下是一个示例创建表的语句：
CREATE TABLE `example_table` (
`id` SERIAL PRIMARY KEY,
`event_time` TIMESTAMP WITH TIME ZONE NOT NULL
);
在INSERT语句中，可以使用CURRENT_TIMESTAMP和SET TIME ZONE语句来插入UTC时间。
INSERT INTO `example_table` (`event_time`) VALUES
(CURRENT_TIMESTAMP AT TIME ZONE ‘UTC’);
在SELECT查询中，您可以使用AT TIME ZONE和TO_CHAR函数将UTC时间转换为本地时间。
SELECT TO_CHAR(`event_time` AT TIME ZONE ‘Asia/Shangh’, ‘YYYY-MM-DD hh:mm:ss’)
FROM `example_table`;
Oracle数据库
在Oracle数据库中，建议使用TIMESTAMP WITH TIMEZONE数据类型来存储UTC时间。以下是一个示例创建表的语句：
CREATE TABLE `example_table` (
`event_time` TIMESTAMP(0) WITH TIME ZONE NOT NULL
);
在INSERT语句中，可以使用SYS_EXTRACT_UTC函数插入UTC时间。
INSERT INTO `example_table` (`event_time`) VALUES
(FROM_TZ(TO_TIMESTAMP(SYSDATE), ‘UTC’));
在SELECT查询中，您可以使用SYS_EXTRACT_UTC函数将TIMESTAMP WITH TIMEZONE转换为UTC时间。
SELECT SYS_EXTRACT_UTC(`event_time`) FROM `example_table`;
结论
不论您使用哪种数据库，存储UTC时间的更佳方法都是将其保存为UTC时间戳，并在需要时将其转换为日期时间。此外，在将时间戳转换为日期时间时，需要注意时间戳是以秒为单位保存的，精确到秒。因此，在您需要更高精度的时间数据时，需要选择其他的解决方案。
相关问题拓展阅读：
mysql中自动插入时间的格式。 我使用mysql 数据库中设置，当有一条数据插入的时候，会自动插入当前时间…
DATE() 日期。格式：YYYY-MM-DD
注释：支持的范围是从 ” 到 ”
DATETIME() *日期和时间的组合。格式：YYYY-MM-DD HH:MM:SS
注释：支持的范围是从 ‘:00:00’ 到 ‘:59:59’
TIMESTAMP() *时间戳。TIMESTAMP 值使用 Unix 纪元(‘:00:00’ UTC) 至今的描述来存储。宽灶格式：YYYY-MM-DD HH:MM:SS
注释：支持的范围是从 ‘:00:01’ UTC 到慎册扮 ‘:14:07’ UTC
TIME() 时间。格式：HH:MM:SS 注释：支持的范围是从 ‘-838:59:59’ 到姿橘 ‘838:59:59’
mysql> SELECT
-> DATE_FORMAT(NOW(), ‘%m-%d’ ) A
看看执行是否正常.
正常的话, 就把 NOW() 替换为你表里面的字圆旁销段名字。 后面再 FROM 你的表。
第二个参数：
%W 星期名字(Sunday……Saturday)
%D 有英语前缀的月份的日期(1st, 2nd, 3rd, 等等。）
%Y 年, 数字, 4 位
%y 年, 数字, 2 位
%a 缩写的星期名字(Sun……Sat)
%d 月份中的天数, 数字启高(00……31)
%e 月份中的天数, 数字(0……31)
%m 月, 数字(01……12)
%c 月, 数字(1……12)
%b 缩写的月份名字(Jan……Dec)
%j 一年中的天数(001……366)
%H 小时(00……23)
%k 小时(0……23)
%h 小时(01……12)
%I 小时(01……12)
%l 小时(1……12)
%i 分钟, 数字(00……59)
%r 时间,12 小时(hh:mm:ss M)
%T 时间,24 小时(hh:mm:ss)
%S 秒(00……59)
%s 秒(00……59)
%p AM或PM
%w 一个星期中的天数(0=Sunday ……6=Saturday ）
%U 星期(0……52), 这里星期天是星期的之一天
%u 星期橘游(0……52), 这里星期一是星期的之一天
%% 一个文字“%”。
所有的其他字符不做解释被复制到结果中。
随着 MySQL 8.0.16 的发布，我们为 MGR 添加了一些功能，以增强其高可用性。其中一个功能是能够在某些情况下启用已离开组的成员自动重新加入，而无需用户干预。
为了理解这个功能的好处以及如何使用它，我们将快速查看它背后的概念以及它首先存在的动机。
介绍
MGR 允许 MySQL 用户轻松管理高可用组，并完成保证系统高可用所需的所有特征，例如容错或故障检测。
MGR 中提供的基本保证之一是该组呈现给用户的是一个不可分割的整体，这意味着一旦成员加入或离开该组，该更改将立即被其他成员得知。默认情况下，组内的数据本身最终是一致的，尽管可以被修改。为了实现这种保证，MGR 使用组成员服务，以及通过一致性算法检测有冲突的事务并中止它们。MGR 的这一方面超出了本文的范围，与成员自动重新加入功能并不完全相关，本文不作赘述。
组内新成员必须符合一些条件。其中新成员需要在事务方面赶上组进度（是通过选择组内一个成员来将已处理的事务流式传输给他，在 MGR 中称坦塌为“捐赠”）。最后，只要在此“分布式恢复”过程中没有遇到任何错误，组内新成员将被声明为 ONLINE 状态。
MGR 依靠组通信层 (GCS) 来管理组。该层实现了用于解决冲突事务的一致性算法，并强制执行一些通信特性。对于实现前面提到的组的不可分割视图，这些特性至关重要，如消息的总顺序、安全传递或视图同步等。
GCS 需要能够检测组中哪些成员失效或看起来失效。一旦这些成员被检测为失效，就将其从该组中移除，以便保持该组正常使用。为此 GCS 在每个成员中引入了一个故障检测器，用于分析组内交换的消息。如果它在一段时间内没有收到来自指定成员的消息，则故障检测器将对该成员产生“怀疑”，并认为该成员可能已经失效。成员从“怀疑”到真正失效的等待时间是可以配置的。
重新加入成员存在的问题
我们已经了解 MGR 必须为了高可用提供的策略，以及它如何实现，接下来请看示例：
一个小组由三个成员组成，其中一个成员偶尔会遇到丢失数据包、断连或者其它导致无法解决的错误情况的影响组内通信。还要考虑这些错误持续时间超过 group_replication_member_expel_timeout的值。
其中一个组员发生故障，小组的其他成员将决定踢出该成员。问题是，一旦该成员重新入组，他将被组驱逐加入失败，需要通过手动干预。
如果该成员的驱逐超时属性设置不为 0，则它将在被驱逐前等待满足该时间量（滚皮将超时设置为 0 意味着他将永远等待）。超时后成员将被驱逐并重新建立连接，并且无法重新加入旧组，需要再次手动干预。
于此，当存在网络故障时，显然需要手动干预。
在 MySQL 8.0.16 中，我们引入了自动重新加入组的功能，一旦成员被驱逐出组，它就会自动尝试重新加入该组，直到达到预设的次数为止。有时每次重试之间至少等待5分钟。
如何启动自动重新加入？
可以通过将group_replication_autorejoin_tries设置为所需的重试次数来开启并使用自动重新加入功能。
SET GLOBAL group_replication_autorejoin_tries = 3
默认值为 0，表示服务器禁用自动重新加入。
如何验证自动重新加入？
与 MySQL 中的许多功能一样，自动重新加入过程是可以监测让备圆的。自动重新加入的可检测性依赖于性能模式基础架构，阶段式收集有关数据。
他们获取以下信息：
事件发生的线程ID（THREAD_ID）
活动名称（EVENT_NAME）
起止时间戳以及事件的总持续时间（TIMER_START，TIMER_END 和 TIMER_WAIT）
在事件停止之前完成的工作单位和预估工作单位（WORK_COMPLETED，WORK_ESTIMATED）
因此，当自动重新加入过程开始时，它将在performance schema中注册一个名为“stage / grouprpl / Undergoing auto-rejoinprocedure”的事件。使用表performance_schema.events_stage_current， performance_schema.events_stages_summary_global_by_event_name和performance_schema.events_stages_history_long我们可以观察到以下内容：
是否正在进行自动重新加入程序
到目前为止，已经减少重试的次数
直到下一次重试的估计剩余时间
自动重新加入过程状态
可以通过过滤包含“auto-rejoin”字符串的活动事件来查找自动重新加入过程状态（即，是否正在进行）：
SELECT COUNT(*) FROM performance_schema.events_stages_current
WHERE EVENT_NAME LIKE ‘%auto-rejoin%’;
COUNT(*)
查询结果存在，证明服务器上运行了自动重新加入过程。
到目前为止的重试次数
如果正在进行自动重新加入程序，我们可以通过选择阶段事件上的工作单元数来检查到目前为止尝试的重试次数：
SELECT WORK_COMPLETED FROM performance_schema.events_stages_current WHERE
EVENT_NAME LIKE ‘%auto-rejoin%’;
WORK_COMPLETED
在这个例子中，到目前为止只有一次尝试。
预计到下次重试的剩余时间
在每次重新加入尝试之间，服务器将处于 5 分钟的可中断睡眠中。 重新加入尝试直到成功或失败之间的时间是无法估计的。 因此，为了粗略估计剩余时间，我们可以将到目前为止尝试的重试次数乘以 5 分钟，并减去到目前为止的阶段事件所花费的时间，以估计我们还需要多长时间：
SELECT (300.0 – ((TIMER_WAIT*10e-12) – 300.0 * num_retries)) AS time_remaining FROM
(SELECT COUNT(*) – 1 AS num_retries FROM
performance_schema.events_stages_current WHERE EVENT_NAME LIKE ‘%auto-rejoin%’) AS T,
performance_schema.events_stages_current WHERE EVENT_NAME LIKE ‘%auto-rejoin%’;
time_remaining
30.0
所以在这个例子中，在下一次重新加入之前还有 30 秒。注意性能模式表中的所有时间记帐都以微秒精度保持，因此我们将 TIMER_WAIT 缩放为秒。
使用自动重新加入与驱逐超时的权衡
到目前为止，在这篇文章中我们只关注自动重新加入。实际上，有两种不同的方法可以实现离开组的成员的重新加入：
设置自动重新加入尝试次数来实现自动重新加入
设置该成员的驱逐超时时间然后配合手动干预
能有延缓删除组内可疑成员，并且如果配置为足够长的驱逐超时时间，则增加了重新建立连接的机会，再次与组进行交互。
虽然这两个功能实现了相同的目标，但它们的工作方式是不同的，并且需要权衡。通过使用驱逐超时，您可以维护组中可疑的成员，其缺点是您无法添加或删除成员或选择新的主机。如果通过使用自动重新加入，该成员将不再是该组的正常组员，将保持在 superreadonly 模式，直到重新加入该组。但在此期间，重新加入成员的同步旧数据的可能性将增加。自动重新加入过程可监控，而驱逐超时不是真正可监控的。
所以，总结一下：
驱逐超时的优点
– 该成员一直在该组内
– 可能更适合足够小的网络故障
驱逐超时的缺点
– 在怀疑某个成员时，无法在该组上添加/删除成员
– 在怀疑某个成员时，无法选择新的主机
– 您无法监控此过程
自动重新加入的优点
– 该组将在没有重新加入成员的情况下运行，您可以添加/删除成员并选择新的主机
– 您可以监控该过程
自动重新加入的缺点
– 您增加了重新加入成员上过时读取的可能性
– 可能不适合足够小的网络故障
总而言之，我从启用自动重新加入中获得了什么？
通过启用自动重新加入，您可以减少对MySQL实例的手动干预的需要。您的系统
更加适应瞬间网络故障，同时满足对容错性和高可用的保证。
摘要
我们引入了一个名为group_replication_autorejoin_tries的新系统变量，允许用户设置 MGR 成员在被驱逐或与组的大多数人失去联系后尝试重新加入组的次数。
go中的时间存入mysql，怎么成了UTC时间了
如果和樱扰mysql的数据类型是date的话 用date(‘Y-m-d’)获取时间
如果是datetime类型，用date(‘Y-m-d H:i:s’)获取时间
个人建议，用int存储，这样占用的的资源小，查询的速度也会快，用time()方法获取时间戳，在调用的时候根据你想要的形式，将时间戳转颂敬换成你要的时间，如果只显示年月日的话，用date(‘Y-m-d’,$date)，如果需要显示精确时间，用date(‘Y-m-d H:i:s’)就可以唤旦了
关于数据库中存储utc时间格式的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
