在Linux C语言开发中，获取当前时间并非单一的操作，而是根据应用场景对精度的不同需求，在time()、gettimeofday()以及clock_gettime()等系统调用或库函数中进行选择，并配合localtime_r()与strftime()进行安全的时间格式化处理，核心上文归纳在于：对于普通的日志记录，使用time()足矣；对于需要微秒级精度的场景，gettimeofday()是传统选择；而在现代高性能服务器开发中，纳秒级精度的clock_gettime()配合CLOCK_MONOTONIC时钟源才是最专业、最可靠的解决方案。
基础秒级时间获取
在大多数不需要高精度时间的应用场景中，例如记录文件创建时间或简单的日志日期，获取从Unix纪元（1970-01-01 00:00:00 UTC）到当前的秒数是最基础的操作，这一功能主要通过标准C库函数time()实现。
该函数接受一个指向time_t类型的指针作为参数，如果指针非空，时间值会被存储在该指针指向的内存中；函数也会返回这个时间值。time_t本质上通常是一个长整型，能够表示的时间范围取决于系统的架构（32位或64位），在64位系统中，这基本解决了“2038年问题”，使用time()函数的优势在于其开销极小，且符合C标准，具有极佳的可移植性，开发者通常获取time_t值后，需要将其转换为人类可读的日期格式,这就需要后续的转换函数介入。
微秒级精度时间获取
随着网络技术的发展，秒级精度往往无法满足需求，在计算网络延迟（RTT）或性能剖析时，我们需要微秒甚至更高的精度，在Linux系统中，gettimeofday()是获取微秒级精度的经典函数。
该函数填充一个struct timeval结构体，其中包含tv_sec（秒）和tv_usec（微秒）两个字段，虽然gettimeofday()在Linux下依然广泛使用，但根据POSIX标准，它已经被标记为“废弃”，这是因为系统时钟的调整（例如NTP同步）会导致时间回跳或跳跃，这对于测量时间间隔来说是不准确的，某些架构下gettimeofday()的实现可能涉及系统调用，频繁调用会带来性能损耗，尽管如此，在旧的代码库维护或对纳秒级精度要求不极端的场合,它依然是一个重要的工具。
纳秒级高精度与单调时钟
在现代Linux C编程，尤其是高频交易、游戏服务器或高精度计时器开发中，clock_gettime()是获取当前时间的最佳实践，它提供了纳秒级精度，并支持多种时钟源,这是其最强大的功能。
最常用的时钟源是CLOCK_REALTIME，它代表系统当前的实时时钟，类似于gettimeofday()，但精度更高，专业开发者更应关注CLOCK_MONOTONIC，这个时钟源代表系统启动后经过的时间，它是单调递增的，不受系统时间修改（如管理员手动修改时间或NTP大幅调整）的影响，这意味着如果你测量两个事件的时间间隔，使用CLOCK_MONOTONIC永远不会得到负值或异常的跳跃值，这对于测量超时、心跳检测等逻辑至关重要。
使用clock_gettime()需要包含<time.h>，并在编译时链接rt库（尽管在较新的glibc版本中这通常是自动的），它填充struct timespec结构体，包含tv_sec（秒）和tv_nsec（纳秒），这种机制保证了在多核、高并发环境下的时间一致性与准确性。
时间格式化与线程安全处理
获取原始的时间戳通常是为了展示或存储，因此需要将其转换为“年-月-日 时:分:秒”的格式，标准库提供了localtime()和gmtime()函数，分别用于转换为本地时区和UTC（协调世界时）。
这里存在一个严重的隐患：线程安全，传统的localtime()函数返回一个指向静态内部缓冲区的指针，在多线程程序中，如果多个线程同时调用该函数，静态缓冲区的数据会被覆盖，导致数据错乱或崩溃，为了解决这个问题，必须使用可重入版本，即localtime_r()和gmtime_r()，这些函数要求调用者自行提供结构体指针,从而避免了静态资源的竞争。
格式化输出则依赖强大的strftime()函数，它允许开发者通过格式化字符串（如”%Y-%m-%d %H:%M:%S”）自定义输出格式，并将结果写入用户提供的缓冲区，结合localtime_r()和strftime()，可以构建出既高效又线程安全的时间字符串生成逻辑,这是生产环境代码的必备素养。
专业开发中的最佳实践
在实际的工程实践中，封装一个统一的时间获取接口是明智之举，应当尽量避免在热路径中频繁进行系统调用，如果对精度要求不高，可以在程序初始化时缓存当前时间，并在循环中通过clock_gettime(CLOCK_MONOTONIC)计算增量来更新逻辑时间,减少对系统时钟的依赖。
处理时区问题时要格外小心，服务器端通常建议统一使用UTC时间进行存储和计算，仅在展示给前端用户时根据用户配置转换为本地时间，这种“存储用UTC，展示用本地”的原则能极大减少夏令时切换带来的逻辑错误。
错误处理不可忽视，尽管时间获取函数很少失败，但在极端系统负载下仍有可能返回错误，专业的代码必须检查返回值，例如clock_gettime()返回-1时，应通过errno判断原因并提供降级方案或日志记录,而不是直接使用未初始化的数据结构。
相关问答
Q1：在Linux C多线程编程中，为什么推荐使用localtime_r而不是localtime？
A： 因为localtime()函数为了性能和简洁，内部使用了一个静态的缓冲区来存储转换结果并返回该缓冲区的指针，在多线程环境下，如果线程A调用了localtime()，在它使用返回的指针之前，线程B也调用了localtime()，线程B的调用会覆盖静态缓冲区中的数据，导致线程A读取到错误的时间信息，进而引发程序逻辑错误甚至崩溃。localtime_r()是可重入（Reentrant）版本，它要求调用者自己分配struct tm结构的内存，由内核将结果写入这块内存，从而完全避免了共享静态资源带来的竞争条件,保证了线程安全。
Q2：CLOCK_REALTIME和CLOCK_MONOTONIC有什么本质区别，在计算耗时时应选哪个？
A： CLOCK_REALTIME代表系统实际的实时时钟，它受系统时间改变的影响，如果管理员手动修改了系统时间，或者NTP服务进行了大幅的时间同步，CLOCK_REALTIME可能会向前跳跃（时间变快）甚至向后回跳（时间变慢），而CLOCK_MONOTONIC代表单调时间，它从系统启动那一刻开始单调递增，不受系统时间修改的影响，在计算两个事件之间的时间间隔（耗时）时，必须使用CLOCK_MONOTONIC，因为如果使用CLOCK_REALTIME，一旦在计时过程中系统时间被调整（例如回跳），计算出的耗时就会变成负数或巨大的数值,导致超时逻辑失效或程序异常。
希望这篇文章能帮助你更好地理解Linux C中时间获取的深层机制，如果你在开发中遇到了关于时间精度或线程安全的特殊挑战，欢迎在评论区分享你的见解或提出疑问,我们可以共同探讨更优的解决方案。
