linux环境下的时间编程

简介:

linux环境下的时间编程
Linux下提供了丰富的api以供开发者们处理和时间相关的问题。然而这些接口看似各自为政实则有有着千丝万缕的联系,在学习和时间中引发了各种各样的混乱。因此时间处理成为了许多Linux开发者的梦魇,遇到时间处理往往避之不及。不过只要你稍微花费一点点精力,学会在Linux上优雅的处理时间和日期也并不是什么难事。

所以本文将会详细介绍Linux api和c标准库对时间的处理,对于更现代化的c++的chrono,会在另一篇文章里再讲。

本文并不会涉及定时器(timer),timer和时间有着关联,而且timer对于程序员来说是极为重要的,但介绍timer接口将会花费相当可观的篇幅,那样多少会使本文离题,所以请允许我在另外的文章中单独讨论timer,这里我们主要集中精力在time pointer和date time上。

本文索引
time的分类
时间的表示
time_t
带有完整日历信息的struct tm
过时的timeval
更现代的timespec
总结
time的分类
在讨论具体的时间问题前,我们先要明确时间的概念。也许你觉得时间的概念是那么浅显易懂没有什么额外强调的必要,但对于程序来说却不然。在程序看来时间的定义是灵活多变的,不同的定义下时间的计算是不同的,因此有必要仔细区分。

一般而言Linux上提供了三种时间,每种时间都包含了自己的含义,起点和特征:

real time
日历时间,又叫wall-clock或者system clock,如同字面意思,是指和真实世界中同样的时间。因此这是最直观最容易理解的时间。
对于Linux世界来说这个时间的起点是1970年1月1日0时(UTC),又被叫做Epoch,Linux上以此为起点的均为UTC时间。

real time的最大特点是会受到修改系统时间的命令/api或者ntp服务的影响,因而导致时间出现跳跃。

monotonic time
单调时间,意思是不能被设置和影响的时间,因此相比系统时钟它可以提供更精确是时间信息,也不会出现时间跳跃。
单调时间的起点POSIX标准并没有明确指定,但在Linux上是以系统启动的时间为起点的。

虽然说单调时钟的时间是稳定的,但它会被adjtime函数和ntp服务影响,同时当系统挂起或休眠时计时会被暂停。

cpu time
程序占用的cpu运行时间。
起点是程序开始运行的时间。

起点说的不是很严谨,因为严格来说cpu time计算的是程序占用的cpu的ticks数,所以程序上的用户等待时间是不包含在内的。

总结一下,前两种是我们接触最多的,系统时间最常见于date time的处理,单调时间则是计时功能和定时器的基石;而cpu time虽然用的少但是在衡量程序性能时是一个重要的参考指标。

时间的表示
存储时间的方法多如牛毛,而对于计算机来说最简单也最有效率的方式便是记录从起点到现在所经过的时间长度。这也是Linux上不同时间表示法的共通之处。

Linux上最常见的时间存储方案有四种:time_t,struct tm,struct timeval和struct timespec。我们分别介绍它们。

time_t
time_t是c和c++标准库的一部分,有标准库背书,因此用的也是最广泛的。

time_t主要表示日历时间,也就是1970/1/1 0:00 UTC开始到现在的秒数。因此一部分的资料会告诉你他是长整数类型比如long的别名,为了方便你可能会将它们转换为整数类型,这时要小心,虽然大多数情况下time_t确实和整数类型有关系,但不同的实现可能使用了不同的整数类型,比如unsigned long和long long,有时候time_t甚至可能是编译器内置类型的别名,所以为了可移植性不要轻易断定它的原始类型是什么。

获得系统时间的方法有如下几种:

// 参数为空指针直接返回当前UTC时间
std::time_t now = std::time(nullptr);

// 参数不为空的时候也会把结果存入参数
std::time_t now_now{};
now = std::time(&now_now);

// 通过tm结构体还原成time_t
std::tm date = {.tm_year = 70}; // 1970/1/1
std::time_t t = std::mktime(&date);
std::cout << std::ctime(&t) << std::endl; // output: Thu Jan 1 00:00:00 1970
一切看起来都很自然,时间的获取就应该是一件简单的事情————真的是这样吗?给出一点提示,最后ctime的输出真的正确吗?

答案很遗憾是否定的。首先我们的系统处于UTC+8时区,我们设置tm为1970年1月1日,因此mktime应该返回0,但当我们用ctime输出本地时间时却发现时间仍然在1970/1/1 0:00:00,而没有如我们预期的那样+8小时,这是为什么呢?

我们的time_t所代表的系统时间又叫做日历时间,是真实世界的时间一致的。而我们知道地球上根据经度不同对于各地区的人来说时间也是不同,因此为了正常生活需要划分出时区;各时区的时间不同,但某些事物会在不同的时区同时发生,因此又需要一个统一的标准时来确定时间,这句是协调世界时(UTC)。

从上面我们可以看到,表达日历时间除了记录时间跨度之外还需要保存时区信息,然而我们的time_t并没有保存时区(timezone)!这是因为标准库把时区的设置交给了系统以及用户自己,在标准库里受到支持的只有local time和UTC time。

因此你会发现标准库函数都对参数是何种时间,返回值是什么时间做了明确的声明。而我们的mktime接受的是_local time_而返回的是_UTC time_,所以time_t所表示的时间比我们预想的差了8小时。

所以我们在Linux上处理时间时一定要注意上下文中时间值附带的时区信息。

带有完整日历信息的struct tm
和time_t息息相关的要数struct tm了,它的声明如下:

struct tm {
int tm_sec; / 秒 [0-60] 允许有1秒的闰秒存在(c++11前和c99前允许2秒的闰秒,所以最大值是61) /
int tm_min; / 分 [0-59] /
int tm_hour; / 时 [0-23] /
int tm_mday; / 日 [1-31] /
int tm_mon; / 月,1月为0 /
int tm_year; / 年份,从1900年开始计算,1970年的值为70 /
int tm_wday; / 星期几,星期天为0,星期六为6,依次递增 /
int tm_yday; / 一年中的第几天,1月1日是0 /
int tm_isdst; / 是否启用夏令时 /
};
当然这只是标准给出的必须要有的成员,实际上在某些bsd系统中struct tm实际上还会包含时区相关的成员,为了写出可移植的代码我们将这些附加内容视为不存在。

获取struct tm除了像我们上一节那样手动指定成员的值之外,还有若干标准库函数可供使用:

// mktime不再赘述,它除了转换tm到time_t之外还可以根据给出的字段自动将tm设置成合理的值
// localtime 认为收到的是local time,返回该local time对应的tm值
// 注意t1复制了返回值,因为localtime,gmtime返回的是static生命周期的指针,无法保证它的值不会被修改
std::time_t now = std::time(nullptr);
std::tm t1 = *std::localtime(&now);

// gmtime 认为接受的是local time,返回将该local time转换为UTC time之后的值
std::tm *t2 = std::gmtime(&now);

// difftime用于比较两个time_t之间相差的秒数
auto time_end = mktime(&t1);
auto time_beg = mktime(t2);
std::cout << std::difftime(time_end, time_beg) << std::endl; // Output: 28800
正如上面代码所示,标准库提供的函数gmtime, localtime, asctime, ctime都使用了函数内的static存储,所以必要的情况下必须把结果值进行拷贝;或者你也可以使用posix提供的带_r后缀的安全版本。

结果是28800秒,也就是8小时,我们所在的时区是UTC+8,符合预期。

此外我们还可以将tm进行格式化输出:

// ctime将接收的time_t视为UTC time,将其转换为local time之后再转换成字符串
// ctime相当于asctime(localtime(...))
std::time_t t1{}; // 默认初始化为0
std::cout << std::ctime(&t1) << std::endl;
// Output: Thu Jan 1 08:00:00 1970

// asctime将收到的tm数据原样输出,不做任何时区的转换
std::tm tm1{};
tm1.tm_year = 70;
tm1.tm_mday = 1;
mktime(&tm1);
std::cout << std::asctime(&tm1) << std::endl;
// Output: Thu Jan 1 00:00:00 1970
此外我们还有strftime和strptime(需要#define _XOPEN_SOURCE)用来将tm格式化为字符串和将字符串解析为tm,限于篇幅我们不过多介绍。

在看过这些常用接口之后,我觉得你现在一定陷入混乱了,因为每个函数对时区的假设都不同,甚至一个函数的参数和返回值的时区也不相同!这就是为什么在Linux上处理时间问题会成为噩梦的原因之一。

你可以靠下图进行简单的记忆,黄色线代表与时区无关,蓝色代表不进行时区转换,红色代表转换为local time,绿色则是UTC time:

至于local和UTC以外的时区怎么办。。。没办法,只能自己手动算时区偏移量了。

过时的timeval
timeval的声明如下:

include

struct timeval {
time_t tv_sec; // 秒
suseconds_t tv_usec; // us 微秒
};

前面两种方案精度只能到秒,而struct timeval可以存储到微秒。timeval除了表示日期类似于time_t之外,还可以用来表示时间跨度(duration):

include // included by time.h

include

struct timeval t;
(void)gettimeofday(&t, nullptr); // UTC

// 使用timeval作为时间长度
struct timeval wait_time = {1, 500000}; // 1.5秒
select(NFDS, read_fds, write_fds, err_fds, &wait_time);
gettimeofday的第二个参数是时区,然而在Linux和glibc上这个参数的实际意义是没有被定义的,所以我们传递nullptr。

由于gettimeofday自身的原因,你通常无法获取到足够到微秒的精度,会存在些许的偏差。另外posix1.2008已经将gettimeofday标记为废弃,因此我们不应该继续使用这一api,因此这里不做过多讨论。

使用timeval结构的函数也少的可怜,只有select和pselect。

更现代的timespec
timespec的声明如下:

include

struct timespec {
time_t tv_sec; // 秒
long tv_nsec; // 纳秒
};
struct timespec是更现代的精度也更高的结构,精度达到了纳秒。同时c11和c++17标准还将其纳入了标准库,因此它现在不再只是posix标准下的了。

获得timespec有两种途径,首先是c和c++标准库提供的方法,我们以c++为例(c的方法完全一样):

std::timespec ts;
timespec_get(&ts, TIME_UTC);
这样我们就获得了现在的UTC时间的值。第二个参数标准目前只定义了TIME_UTC,所以现在还无法直接获取其他时区的时间值。

获取timespec的第二种方法就是使用posix的clock_gettime,它不仅能获得自1970/1/1开始的时间,还可以自定义clock的类型以便获取不同的时间值,现在是被推荐的用于获取时间的接口,在需要获取较高精度的时间值时应该优先考虑使用它:

include

include

include

void print_time(const char id, const struct timespec t)
{

printf("%s:\nseconds: %ld nanoseconds: %ld\n\n", id, t->tv_sec, t->tv_nsec);

}

// 获取不同时钟的时间值并打印,不支持的时钟类型会让clock_gettime返回-1
// 你不应该模仿这个宏,我只是单纯在偷懒而已

define get_clock(clk_id) \

do { \
    if (clock_gettime(clk_id, &t) != 0) { \
        printf("this system doesn't support the " #clk_id "clock\n"); \
    } \
    print_time(#clk_id, &t); \
    memset(&t, 0, sizeof(struct timespec)); \
} while (0)

int main(void)
{

struct timespec t = {0, 0};
// 日历时间,UTC
get_clock(CLOCK_REALTIME);

// 单调时钟时间,从系统启动开始计算
get_clock(CLOCK_MONOTONIC);

// 类似单调时钟,但是包含了系统休眠时经过的时间
get_clock(CLOCK_BOOTTIME);

}
输出如下:

CLOCK_REALTIME:
seconds: 1585273480 nanoseconds: 594245824

CLOCK_MONOTONIC:
seconds: 12018 nanoseconds: 401860644

CLOCK_BOOTTIME:
seconds: 12018 nanoseconds: 401863344
因为我的系统并没有休眠,所以BOOTTIME和MONOTONIC的值是相同的。

还有更多的时钟类型,比如基于硬件的更快的单调时钟和系统时钟,记录进程/线程消耗cpu时间的时钟等,具体参见man pages。

timespec的应用也相当广泛,在clock_nanosleep,nanosleep,pthread等系统调用和库中都被广泛使用。

比如在pthread中我们规定等待互斥锁2.5秒,超时就重试或放弃:

struct timespec timeout;
clock_gettime(CLOCK_REALTIME, &timeout);
timeout.tv_sec += 2;
timeout.tv_nsec += 50000000;
pthread_mutex_timedlock(&mutex, &timeout);
从上面可以看出超时是根据系统时间进行判断的,通过设置mutex是属性,我们还可以使用更为准确的单调时钟。

总结
本文我们介绍了c/c++标准库以及Linux提供的time api一共两套时间处理方案。

对于简单的date time的处理和获取time pointer,标准库的功能就足够了;而对于超时/延时任务以及需要更高精度时间的场合我们需要系统调用的帮助。

两套api间可以在损失微秒/纳秒精度的前提下进行转换,因为tv_sec成员都是time_t类型的。

两套api各有所长,然而都有一个缺点————无法处理时区。在不引入第三方库和自己手动计算的情况下,Linux处理时区的手段只有以下两种:

函数自己定义参数和返回值使用local time还是UTC time;
系统根据环境变量TZ以及配置文件/etc/localtime等改变本地时间(local time)。
因此在处理时间时我们始终要注意当前被处理的时间是解释成本地时间还是UTC时间;同时还要注意获得的时间的本地还是UTC。因此时间处理问题不可避免的变得十分复杂,某些使用夏令时的地区这一问题还会被继续放大。

当然,如果你不想用这么底层的时间处理方法,还有类似xTime,libtai,boost_date_time这样的第三方库可以使用。

作者:@apocelipes
本文为作者原创,转载请注明出处:https://www.cnblogs.com/apocelipes/p/12579956.html

相关文章
|
14天前
|
关系型数据库 MySQL Linux
|
17天前
|
Linux
FFmpeg开发笔记(三十四)Linux环境给FFmpeg集成libsrt和librist
《FFmpeg开发实战》书中介绍了直播的RTSP和RTMP协议,以及新协议SRT和RIST。SRT是安全可靠传输协议,RIST是可靠的互联网流传输协议,两者于2017年发布。腾讯视频云采用SRT改善推流卡顿。以下是Linux环境下为FFmpeg集成libsrt和librist的步骤:下载安装源码,配置、编译和安装。要启用这些库,需重新配置FFmpeg,添加相关选项,然后编译和安装。成功后,通过`ffmpeg -version`检查版本信息以确认启用SRT和RIST支持。详细过程可参考书中相应章节。
26 1
FFmpeg开发笔记(三十四)Linux环境给FFmpeg集成libsrt和librist
|
12天前
|
安全 Ubuntu Linux
6 个受欢迎且好用的轻量级Linux桌面环境
Linux被认为是最安全的系统,但这并不意味着它不受恶意软件或其他安全漏洞的侵害。Linux系统的使用范围非常广泛,因此防范潜在威胁至关重要。在这里,将探索 2024 年适用于 Linux 的最佳防病毒软件。根据评级、功能以及与其他 Linux 发行版的兼容性列出了十款最佳防病毒软件,内容仅供分享,不做其它用途。
80 0
6 个受欢迎且好用的轻量级Linux桌面环境
|
17天前
|
Linux 网络安全 开发工具
linux 常用命令【编程必备】
linux 常用命令【编程必备】
26 4
|
18天前
|
小程序 Linux
【编程小实验】利用Linux fork()与文件I/O:父进程与子进程协同实现高效cp命令(前半文件与后半文件并行复制)
这个小程序是在文件IO的基础上去结合父子进程的一个使用,利用父子进程相互独立的特点实现对数据不同的操作
|
18天前
|
缓存 网络协议 算法
【Linux系统编程】深入剖析:四大IO模型机制与应用(阻塞、非阻塞、多路复用、信号驱动IO 全解读)
在Linux环境下,主要存在四种IO模型,它们分别是阻塞IO(Blocking IO)、非阻塞IO(Non-blocking IO)、IO多路复用(I/O Multiplexing)和异步IO(Asynchronous IO)。下面我将逐一介绍这些模型的定义:
|
17天前
|
Linux 网络安全 虚拟化
Ngnix04系统环境准备-上面软件是免费版的,下面是收费版的,他更快的原因使用了epoll模型,查看当前Linux系统版本, uname -a,VMWARE建议使用NAT,PC端电脑必须使用网线连接
Ngnix04系统环境准备-上面软件是免费版的,下面是收费版的,他更快的原因使用了epoll模型,查看当前Linux系统版本, uname -a,VMWARE建议使用NAT,PC端电脑必须使用网线连接
|
18天前
|
Linux Docker 容器
Docker02--搭建Linux环境,配置Docker,docker images无法访问,因为docker没有启动,阿里云镜像加速器免费的
Docker02--搭建Linux环境,配置Docker,docker images无法访问,因为docker没有启动,阿里云镜像加速器免费的
|
18天前
|
负载均衡 Java Linux
黑马头条01,环境搭建,今日头条的介绍,今日头条的功能架构图,技术栈的说明,服务层,nacos(奶靠丝)安装,安装在Linux服务器上环境准备,
黑马头条01,环境搭建,今日头条的介绍,今日头条的功能架构图,技术栈的说明,服务层,nacos(奶靠丝)安装,安装在Linux服务器上环境准备,
|
21天前
|
Linux
【问题解决】Linux环境下pip下载缓慢
【问题解决】Linux环境下pip下载缓慢
11 0