问题标签 [year2038]

正如标题所示，我使用公式创建了一个结果，但现在需要将其分解为为每个“所有者”运行公式，但将公式分成几年。我的日期是 2010-2019。这是代码

从最终选项卡中选择 *；

选择 finaltab.OWNER 作为 OWNER，SUM(finaltab.shares) A​​S SSUM FROM finaltab WHERE trancode='S' GROUP BY OWNER 按年份排序；选择 finaltab.OWNER 作为 OWNER，SUM(finaltab.shares) A​​S PSUM FROM finaltab WHERE trancode='P' GROUP BY OWNER 按年份排序；

SELECT finaltab.OWNER, SSUM, PSUM FROM (SELECT finaltab.OWNER AS OWNER, SUM(finaltab.shares) A​​S SSUM FROM finaltab WHERE trancode='S' GROUP BY OWNER) 作为稳定的内部连接 ​​(SELECT finaltab.OWNER AS OWNER, SUM (finaltab.shares) 作为来自 finaltab 的 PSUM WHERE trancode='P' GROUP BY OWNER) 作为 PTable ON (Stable.owner = Ptable.owner);

SELECT STable.OWNER, SSUM, PSUM, (PSUM - SSUM) / (PSUM + SSUM) as "IOF" FROM (SELECT finaltab.OWNER as OWNER, SUM(finaltab.shares) A​​S SSUM From finaltab WHERE trancode='S' GROUP BY OWNER）作为稳定的内部联接（选择 finaltab.OWNER 作为 OWNER，SUM（finaltab.shares）作为 PSUM 从 finaltab WHERE trancode='P' GROUP BY OWNER）作为 PTable ON（STable.OWNER = PTable.OWNER）；

这是桌子。另外，如果我想采用“IOF”或公式并将其实现为具有分子中“IOF”绝对值的公式，我还想了解一些方向。谢谢[1]：https ://i.stack.imgur.com/P9GtU.png

我正在尝试将我的 32 位 ARM 架构移植到 64 位时间值。

从Linux Kernel 中的 64 位 time_t读取答案，它告诉我以下信息：

所有用户空间都必须使用 64 位 time_t 进行编译，即将到来的 musl-1.2 和 glibc-2.32 版本以及已安装的 linux-5.6 或更高版本的内核头文件都将支持它。

我正在使用自定义 Linux 内核版本 5.10.10 并使用 glibc 版本 2.32 使用 crosstool-ng 构建我自己的 gcc 工具链。

为了测试时间大小，我写了一个简单的打印：

这给了我输出：

时间大小 = 32

time_t 的大小 = 4

按照glibc-2.32中的defines和typedefs，可以看到相关类型定义如下：

但是对于我的架构来说__WORDSIZE，__SLONGWORD_TYPE它们的大小都是 32 位的。

是否可以time_t在我的 32 位架构目标上定义为 64 位？

在我的应用程序中，当系统时间设置为 2038 时，MQReceiveMessage 没有收到消息。对于 2038 年是否有任何 MSMQ 限制

错误： SQL 编译错误：[DX.PATIENTID] 不是有效的 group by 表达式

我的 CPU 是armhf32 位的。我Linux Kernel 5.4在它上面运行（所以它支持 32 位系统的 64 位 time_t）。我针对程序编译glibc 2.34（因此 time_t 可以明确设置为 64 位而不是 32 位）。

现在我试图让这段简单的代码工作（test.c）。

（交叉）像这样编译它：

为了测试程序，我将系统日期设置为 2084-01-01（2038 年之后很重要）。然后我通过运行创建一个文件touch /tmp/testme.file。此文件的创建时间戳为 2084-01-01。现在，当我运行上面的代码./test时，它给了我这个错误消息：

似乎Value too large for defined data type发生错误，因为该函数lchmod(...)无法处理创建时间戳超过 2038 年的文件。

为什么是这样？这是一个 glibc 错误还是必须用额外的 CFLAGS 重新编译glibc 2.34 它本身-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64。

当我改变lchmod(...)它的chmod(...)工作。

摘自cppref：

std::time_t32 位有符号整数的实现（许多历史实现）在 2038 年失败。

但是，文档没有说明如何检测当前的实现是否是 2038 安全的。所以，我的问题是：

如果在 C++ 中，它是否保证 2038 安全？sizeof(std::time_t) == sizeof(std::uint64_t)

我正在尝试构建一个基于 glibc 库的 Yocto(honister) 图像。即使我使用内核 5.6 和 glibc-2.34 并使用 -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 编译 poky 但 _TIMESIZE 仍然是 4 字节。我可以将日期设置为 2039+ 年，但是当我读取 %s 格式结果为 -1 时。

$日期-s“2222-01-01”

2222 年 1 月 1 日星期二 00:00:00 UTC

$日期 +%s

-1

（基于 musl 的图像正常工作）

我的方法：在 build/local.conf TARGET_CPPFLAGS += "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" 中定义 TARGET_CPPFLAGS

用户空间应该使用该标志进行编译，但是 yocto 中还有另一种方法吗？还是我做错了？