做了这么多年Linux运维我发现自己用得最多的命令其实不是那些花里胡哨的文本处理工具反而是date——一个看起来简单到不需要学的命令。我见过太多同事在写备份脚本、排查日志时间、处理定时任务时被日期格式化折腾得焦头烂额甚至有人辛辛苦苦写完同步脚本结果因为时间戳不对导致备份覆盖了昨天的数据。这篇文章就把date命令从显示、格式化、时间运算到系统管理实战完整拆开讲一遍每一段都有实际验证过的用法和踩坑教训适合刚接触Linux的新手也适合日常写脚本的运维和开发同学参考。1. date命令的显示与格式化先把手头的活儿干明白1.1 不带参数的date到底输出了什么直接在终端输入date大部分人都会得到类似这样的输出$ date Fri Dec 20 10:30:45 CST 2024这串内容里包含了星期几、月份、日期、时分秒、时区缩写CST代表中国标准时间和年份。说实话这种格式看一次两次还行但要在脚本里用它做变量、拼文件名直接抓这串文本去处理那纯属给自己找麻烦。真正干活的时候我们几乎总是用date 格式串这个方式。很多人第一次看到date %Y-%m-%d会疑惑为什么加号后面还要带引号原因很简单%在Linux shell里是有特殊含义的尤其是在echo、printf或者bash的某些扩展场景里不包引号极有可能被解释成别的意思。为了避免这种奇奇怪怪的问题我的习惯是只要用了格式化符号就老老实实加上双引号。$ date %Y-%m-%d %H:%M:%S 2024-12-20 10:30:45这条命令输出的就是标准的年月日时分秒这个格式在任何系统日志、数据库记录里都是通用的干净、直观、好比较大小。做运维的应该把它当成肌肉记忆。1.2 格式化符号速查与示例date命令的格式化符号有好几十个但真正高频用到的不超过20个。我把常用的整理成了一张表建议存下来符号含义示例输出以2024-12-20 10:30:45为例%Y四位数年份2024%y两位数年份24%m两位数月份12%d两位数日期20%H24小时制小时10%M分钟30%S秒45%F等价于%Y-%m-%d2024-12-20%T等价于%H:%M:%S10:30:45%u星期几1周一7周日5%w星期几0周日6周六5%A完整星期名Friday%a缩写星期名Fri%B完整月份名December%b缩写月份名Dec%j一年中的第几天001-366355%s从1970-01-01 00:00:00 UTC到现在的秒数1734658245%N纳秒123456789%z时区偏移量0800上面表格里我最常用的是%F和%T这两个组合因为它们不用再单独拼横线和冒号写脚本的时候能少打不少字。比如生成日志文件名我经常这样写$ date %F_%T 2024-12-20_10:30:45这种文件名排序的时候非常舒服字符串天然就是时间顺序。不过要提醒一点文件名里带冒号在一些Windows共享目录或者某些特殊文件系统上会有问题所以如果这个文件可能要跨平台使用把%T换成%H%M%S更稳妥也就是2024-12-20_103045这种。1.3 系统管理里最常见的几种格式化组合结合我做运维的经验下面几组组合基本覆盖了日常90%的需求日志文件按天切割date %Y%m%d得到20241220配合logrotate或者自己写mv命令都方便。备份文件精确到分钟date %Y%m%d_%H%M得到20241220_1030避免同一天多次备份时互相覆盖。时间戳用于数据库导入导出date %F %T得到2024-12-20 10:30:45很多数据库的时间字段原生支持这个格式。用于日志输出的正则匹配date %d/%b/%Y:%H:%M:%S说实话这是我在分析Nginx访问日志时最常用的一个因为Nginx默认日志格式就是20/Dec/2024:10:30:45 0800这种。2. 修改系统时间date的超级权限玩法2.1 date -s 设置时间的正确姿势date -s命令用于修改系统时间它要求你有root权限。基本用法是$ sudo date -s 2024-12-20 10:30:00也可以只改时间不动日期$ sudo date -s 10:30:00或者只改日期不动时间$ sudo date -s 2024-12-20这里我遇到了不止一次的坑date -s对格式特别敏感一旦没按它规定的模式写系统会直接报错invalid date。最稳妥的写法就是把年月日和时间用空格隔开然后整体用引号包起来。设置完成后马上用date验证一遍确认输出正确再往下走。不过我不建议在生产环境手忙脚乱地靠date -s改时间。如果你处理的是运行着数据库的主机时间被强行改大或改小可能引发主从复制异常、定时任务乱跳这些问题。我自己处理过一台MySQL主从服务器因为管理员手动把时间往后调了半小时结果binlog的时间戳和relay log对不上从库直接罢工。真要手动校准时间建议先停应用再操作改完之后立刻重启相关服务。2.2 为什么设置完时间还要碰硬件时钟Linux系统里有两个时钟一个是系统时钟System Clock也就是我们前面date命令操作的这个另一个是硬件时钟Hardware Clock / RTC它由主板上的电池供电关机后依然在走。系统启动的时候内核会从硬件时钟读取时间作为初始值系统运行期间date命令修改的是内存里的系统时钟。这就导致一个经典问题关机后你手动用date改的时间不会自动保存到硬件时钟。如果只改了系统时间第二天一开机你会发现时间又跳回原来那个不对的值了。解决办法是用hwclock命令把系统时间同步到硬件时钟$ sudo hwclock --systohc--systohc的意思是把系统时间(System Time)写入硬件时钟(Hardware Clock)。反过来如果你发现系统时间和硬件时钟差了太多想用硬件时间覆盖系统时间就跑$ sudo hwclock --hctosys我在做服务器初始化的时候固定流程就是先date -s把系统时间设对再hwclock --systohc把硬件时钟也校准最后用hwclock -r读一遍硬件时钟确认。这个习惯让我后来少处理了很多为什么重启后时间又错了的问题。2.3 时区问题为什么date显示的时间总是不对date显示的时间不对可能不是时间没设对而是时区不对。国内服务器一般用CST中国标准时间UTC8如果系统时区被设置成UTC即使硬件时钟没问题date输出也会比北京时间慢8个小时。检查当前时区$ timedatectl这个命令会列出本地时间、UTC时间、时区、是否启用NTP等关键信息。修改时区最直接的方式$ sudo timedatectl set-timezone Asia/Shanghai设置完成后再执行date应该就能看到正确的CST和北京时间了。如果你不想动全局时区只想让当前shell临时用某个时区可以直接改TZ这个环境变量$ TZAmerica/New_York date这行命令的效果是只针对这一次date调用按照纽约时区输出时间不影响系统全局设置。这个方法在做跨时区数据分析或测试的时候很实用。我用一个简化版的对比来总结时区与时钟的关系操作影响范围是否持久适用场景date -s仅系统时钟否重启丢失临时校准系统时间hwclock --systohc写入硬件时钟是校准后固化时间timedatectl set-timezone时区配置是修正时区错误TZ变量仅当前命令/会话否临时跨时区显示3. 时间运算让date帮你算加减法和时间差3.1 -d参数一个被严重低估的宝藏date的-d参数可以解析一个时间表达式然后输出格式化后的结果。这是我在写自动化脚本时最喜欢的特性因为它能直接处理昨天下周30天前这类自然语言级别的需求。看几个实际例子# 显示昨天 $ date -d yesterday %F # 显示30天前的日期 $ date -d -30 days %F # 显示7天后的日期 $ date -d 7 days %F # 显示下周一 $ date -d next monday %F # 显示本月最后一天 $ date -d $(date %Y%m01) 1 month -1 day %F最后那个写法稍微有点绕但原理很简单先拼出这个月的1号然后加1个月得到下个月1号再减1天就得到本月最后一天。这种组合表达式GNU date是支持的Debian/Ubuntu、CentOS/RHEL这些都跑GNU coreutils基本都兼容。如果服务器上装的是busybox或者其他精简版date可能不支持这些自然语言表达式。我在嵌入式设备上遇到过多次这个问题报错信息通常就是invalid date。这种环境下只能用笨办法把时间转成秒数自己加减86400秒再转回来。$ date -d $(( $(date %s) - 86400 )) %F这条命令先取当前时间的Unix秒数减去8640024小时的秒数再用-d 秒数的方式转成日期字符串。虽然看着麻烦但胜在通用。3.2 计算时间差秒数才是硬通货脚本里经常需要统计一段操作的耗时最朴素可靠的方法就是用%s秒数start$(date %s) # 中间执行一些耗时操作 sleep 5 end$(date %s) cost$((end - start)) echo 耗时 ${cost} 秒只要把%s这个时间戳理解为自1970年以来的秒数很多时间计算都会变得特别清爽。比如判断一个文件是否超过7天没更新可以先算当前秒数减去文件的mtime秒数now$(date %s) file_time$(stat -c %Y /var/log/app.log) diff$(( (now - file_time) / 86400 )) if [ $diff -gt 7 ]; then echo 日志文件已经 $diff 天没有更新了 fi这里我用stat -c %Y拿到文件的最后修改时间戳date %s拿到当前时间戳两者相减再除以86400得到天数。用这种方式处理时间比较比直接比较字符串格式的日期要可靠得多因为格式稍微一乱字符串排序就不可信了。3.3 时间戳与反向解析拿秒数还原时间有时候我们从数据库或配置里拿到的是一个Unix时间戳比如1734658245人眼根本看不出来这是什么时候。这时候用date反向解析$ date -d 1734658245 %F %T 2024-12-20 10:30:45我在分析应用日志时经常遇到这种场景程序只记录了毫秒级时间戳我得先换算成可读时间再去和错误日志做比对。一条命令搞定效率高很多$ date -d 1734658245 %F %T如果时间戳带毫秒需要先去掉毫秒部分或者用小数点精度$ date -d 1734658245.123 %F %T.%N不过说实话日常排查问题我都是先取整秒毫秒一般只在性能分析时才看。输出纳秒的%N用得也少除非你确实在做高精度的基准测试。4. 系统管理实战date在日志、备份、计划任务里的常规应用4.1 日志文件按日期轮转一个很常见的需求每天生成一个独立的日志文件方便查找和清理。手动写的话可以这样LOG_FILE/var/log/app_$(date %Y%m%d).log然后你的程序往这个文件写内容第二天就会因为日期变了、文件名也跟着变自然生成一个新文件。这样做的好处是日志清理可以做成这样# 删除5天前的日志文件 find /var/log -name app_*.log -mtime 5 -delete这里mtime按文件修改时间匹配由于日志文件的名字和修改时间天然一致清理逻辑非常清晰。我见过不少新手会把日期写死在配置里结果日志永远只有一个文件越来越庞大等发现时已经占用几十GB磁盘。养成用date动态生成日志名的习惯能省掉很多运维麻烦。4.2 备份脚本里的时间戳防止覆盖的关键备份脚本是这个道理最典型的应用场景。不使用时间戳的备份脚本长这样tar czf /backup/etc.tar.gz /etc这个脚本有个致命问题每天跑一次今天的备份会直接覆盖昨天万一昨天是好的、今天是坏的你根本没有回退的机会。稍微改进一下backup_date$(date %Y%m%d_%H%M%S) tar czf /backup/etc_${backup_date}.tar.gz /etc这样就保证每次备份生成的都是独立文件。配合find清理旧备份find /backup -name etc_*.tar.gz -mtime 30 -delete这招在做数据库逻辑备份时尤其救命。我曾经在凌晨2点的crontab任务里遇到过备份脚本执行到一半系统崩溃第二天早上才发现昨晚的备份文件没生成因为文件名里带时间戳前后几天的备份都在损失可控。换成不带时间戳的覆盖式备份那天就真的全没了。4.3 date、crontab与%转义问题crontab里直接用date命令时很多新手会被%号坑吐。看这个例子我想把任务日志按分钟归档*/5 * * * * echo time is $(date %F_%T) /tmp/time.log如果你直接把这个写进crontab大概率会出错或得到奇怪的结果。原因在于crontab默认情况下%是特殊字符会被解释成换行符。解决办法是给%加反斜杠转义*/5 * * * * echo time is $(date \%F_\%T) /tmp/time.log或者更干净的做法把date命令单独抽到一个脚本文件里在脚本里正常写%crontab只调用脚本。我个人的习惯就是后者因为脚本里不用考虑这些转义读起来也直观以后要加逻辑也不至于在crontab里改得乱七八糟。另外crontab里的date还有个隐含坑它用的是当前shell环境里的时区设置。如果你在crontab文件头里没设置TZ不同发行版的行为可能不一样。稳健的做法是在脚本开头写上export TZAsia/Shanghai或者直接依赖系统时区统一确保timedatectl里设置的是预期的区域。5. date命令那些反直觉的坑5.1 系统时间与硬件时间打架这个坑我在2.2里简单提过这里说一个具体排查案例。有次项目组反馈说一台数据库服务器每天凌晨4点重启后时间总会自己跳回昨天。我排查的时候先跑了date看到系统时间是对的又跑hwclock -r看硬件时间才发现硬件时钟停留在两天前的值。重启时内核从硬件时钟读时间就把系统时间带偏了。问题根因就是之前有人直接date -s改了系统时间但没有执行hwclock --systohc同步到硬件时钟。长时间断电后电池电路又让硬件时钟本身产生了偏差于是一重启就暴露了。解决办法很简单先把硬件时钟校准$ sudo hwclock --systohc然后建议启用NTP时间同步避免时间长期漂移$ sudo timedatectl set-ntp true如果你在公司内网、没有外网的NTP服务可以在内网架一台NTP服务器或者用业务系统里已有的时间源。5.2 时区写在环境变量里造成的诡异局面还有一个容易被忽略的坑当TZ环境变量被设置成奇怪的值时date输出会异常。比如某次我排查一个用户现场脚本里只要一执行date输出的时区就是UTC8但系统的timedatectl明明显示Asia/Shanghai。查到最后发现是/etc/profile里有段陈年旧代码导出了TZUTC-8。这里要特别说明一个反直觉的点POSIX风格的TZ里UTC-8反而代表的是UTC8因为POSIX时区定义的符号和日常直觉是反的正数表示西区负数表示东区。所以看到TZ的值是负数不代表就是东八区。这背后的深水太深建议别折腾直接用Asia/Shanghai这种Olson数据库的时区名更不容易出错。排查环境变量型时区问题的命令是$ echo $TZ $ env | grep TZ如果发现有输出再看它是从哪个配置文件加载的$ grep TZ /etc/profile /etc/bash.bashrc ~/.bashrc ~/.profile 2/dev/null找到后把错误导出删掉重新登录shell就正常了。5.3 脚本里调用date时常见的其他坑再补充几个我在跨平台、跨环境时遇到的细节问题。第一个是date -d这个参数在macOS的BSD date里不存在在Solaris和一些老Unix里也未必支持。如果你写的脚本要在Linux和macOS之间来回跑就要考虑兼容写法一种是用date -v-1d这种macOS专用参数另一种是干脆统一用python3 -c来做时间运算或者用date %s自行算术。我在团队里会约定所有要跨平台的脚本一律采用纯秒数运算不依赖-d的自然语言解析。第二个是格式化字符串里如果没有用双引号包裹在部分shell的某些场景下会触发历史扩展导致命令被替换成奇怪内容。这个在交互式shell里按!开头的时候最容易踩但脚本里为了保险还是养成熟练加引号的习惯。第三个是关于date的%N虽然能输出纳秒但如果脚本里多次调用date %s%N存在极低的重复概率在高并发下生成唯一ID并不可靠。你要真拿它当随机数来源是会出事儿的。唯一ID用uuidgen或/proc/sys/kernel/random/uuid更合适。Time management is one of those things that seems trivial until it bites you. 我在实际运维中观察到的经验是date命令的很多坑并不在于date本身而在于我们对时间的理解不够系统。系统时钟、硬件时钟、时区、UTC偏移、Unix时间戳这些概念搞明白了date命令的所有参数就都是具体工具而已不会再有什么神秘感。最后分享一个小技巧我在每台服务器上都习惯放一个简单的环境检查脚本里面第一行就是date %F %T %z %Z登录后先执行它确认时间和时区正确再去做其他操作这个习惯帮我提前发现过好几次时区漂移问题属于性价比极高的几秒钟。
Linux date命令完全指南：格式化、时间运算与实战避坑
做了这么多年Linux运维我发现自己用得最多的命令其实不是那些花里胡哨的文本处理工具反而是date——一个看起来简单到不需要学的命令。我见过太多同事在写备份脚本、排查日志时间、处理定时任务时被日期格式化折腾得焦头烂额甚至有人辛辛苦苦写完同步脚本结果因为时间戳不对导致备份覆盖了昨天的数据。这篇文章就把date命令从显示、格式化、时间运算到系统管理实战完整拆开讲一遍每一段都有实际验证过的用法和踩坑教训适合刚接触Linux的新手也适合日常写脚本的运维和开发同学参考。1. date命令的显示与格式化先把手头的活儿干明白1.1 不带参数的date到底输出了什么直接在终端输入date大部分人都会得到类似这样的输出$ date Fri Dec 20 10:30:45 CST 2024这串内容里包含了星期几、月份、日期、时分秒、时区缩写CST代表中国标准时间和年份。说实话这种格式看一次两次还行但要在脚本里用它做变量、拼文件名直接抓这串文本去处理那纯属给自己找麻烦。真正干活的时候我们几乎总是用date 格式串这个方式。很多人第一次看到date %Y-%m-%d会疑惑为什么加号后面还要带引号原因很简单%在Linux shell里是有特殊含义的尤其是在echo、printf或者bash的某些扩展场景里不包引号极有可能被解释成别的意思。为了避免这种奇奇怪怪的问题我的习惯是只要用了格式化符号就老老实实加上双引号。$ date %Y-%m-%d %H:%M:%S 2024-12-20 10:30:45这条命令输出的就是标准的年月日时分秒这个格式在任何系统日志、数据库记录里都是通用的干净、直观、好比较大小。做运维的应该把它当成肌肉记忆。1.2 格式化符号速查与示例date命令的格式化符号有好几十个但真正高频用到的不超过20个。我把常用的整理成了一张表建议存下来符号含义示例输出以2024-12-20 10:30:45为例%Y四位数年份2024%y两位数年份24%m两位数月份12%d两位数日期20%H24小时制小时10%M分钟30%S秒45%F等价于%Y-%m-%d2024-12-20%T等价于%H:%M:%S10:30:45%u星期几1周一7周日5%w星期几0周日6周六5%A完整星期名Friday%a缩写星期名Fri%B完整月份名December%b缩写月份名Dec%j一年中的第几天001-366355%s从1970-01-01 00:00:00 UTC到现在的秒数1734658245%N纳秒123456789%z时区偏移量0800上面表格里我最常用的是%F和%T这两个组合因为它们不用再单独拼横线和冒号写脚本的时候能少打不少字。比如生成日志文件名我经常这样写$ date %F_%T 2024-12-20_10:30:45这种文件名排序的时候非常舒服字符串天然就是时间顺序。不过要提醒一点文件名里带冒号在一些Windows共享目录或者某些特殊文件系统上会有问题所以如果这个文件可能要跨平台使用把%T换成%H%M%S更稳妥也就是2024-12-20_103045这种。1.3 系统管理里最常见的几种格式化组合结合我做运维的经验下面几组组合基本覆盖了日常90%的需求日志文件按天切割date %Y%m%d得到20241220配合logrotate或者自己写mv命令都方便。备份文件精确到分钟date %Y%m%d_%H%M得到20241220_1030避免同一天多次备份时互相覆盖。时间戳用于数据库导入导出date %F %T得到2024-12-20 10:30:45很多数据库的时间字段原生支持这个格式。用于日志输出的正则匹配date %d/%b/%Y:%H:%M:%S说实话这是我在分析Nginx访问日志时最常用的一个因为Nginx默认日志格式就是20/Dec/2024:10:30:45 0800这种。2. 修改系统时间date的超级权限玩法2.1 date -s 设置时间的正确姿势date -s命令用于修改系统时间它要求你有root权限。基本用法是$ sudo date -s 2024-12-20 10:30:00也可以只改时间不动日期$ sudo date -s 10:30:00或者只改日期不动时间$ sudo date -s 2024-12-20这里我遇到了不止一次的坑date -s对格式特别敏感一旦没按它规定的模式写系统会直接报错invalid date。最稳妥的写法就是把年月日和时间用空格隔开然后整体用引号包起来。设置完成后马上用date验证一遍确认输出正确再往下走。不过我不建议在生产环境手忙脚乱地靠date -s改时间。如果你处理的是运行着数据库的主机时间被强行改大或改小可能引发主从复制异常、定时任务乱跳这些问题。我自己处理过一台MySQL主从服务器因为管理员手动把时间往后调了半小时结果binlog的时间戳和relay log对不上从库直接罢工。真要手动校准时间建议先停应用再操作改完之后立刻重启相关服务。2.2 为什么设置完时间还要碰硬件时钟Linux系统里有两个时钟一个是系统时钟System Clock也就是我们前面date命令操作的这个另一个是硬件时钟Hardware Clock / RTC它由主板上的电池供电关机后依然在走。系统启动的时候内核会从硬件时钟读取时间作为初始值系统运行期间date命令修改的是内存里的系统时钟。这就导致一个经典问题关机后你手动用date改的时间不会自动保存到硬件时钟。如果只改了系统时间第二天一开机你会发现时间又跳回原来那个不对的值了。解决办法是用hwclock命令把系统时间同步到硬件时钟$ sudo hwclock --systohc--systohc的意思是把系统时间(System Time)写入硬件时钟(Hardware Clock)。反过来如果你发现系统时间和硬件时钟差了太多想用硬件时间覆盖系统时间就跑$ sudo hwclock --hctosys我在做服务器初始化的时候固定流程就是先date -s把系统时间设对再hwclock --systohc把硬件时钟也校准最后用hwclock -r读一遍硬件时钟确认。这个习惯让我后来少处理了很多为什么重启后时间又错了的问题。2.3 时区问题为什么date显示的时间总是不对date显示的时间不对可能不是时间没设对而是时区不对。国内服务器一般用CST中国标准时间UTC8如果系统时区被设置成UTC即使硬件时钟没问题date输出也会比北京时间慢8个小时。检查当前时区$ timedatectl这个命令会列出本地时间、UTC时间、时区、是否启用NTP等关键信息。修改时区最直接的方式$ sudo timedatectl set-timezone Asia/Shanghai设置完成后再执行date应该就能看到正确的CST和北京时间了。如果你不想动全局时区只想让当前shell临时用某个时区可以直接改TZ这个环境变量$ TZAmerica/New_York date这行命令的效果是只针对这一次date调用按照纽约时区输出时间不影响系统全局设置。这个方法在做跨时区数据分析或测试的时候很实用。我用一个简化版的对比来总结时区与时钟的关系操作影响范围是否持久适用场景date -s仅系统时钟否重启丢失临时校准系统时间hwclock --systohc写入硬件时钟是校准后固化时间timedatectl set-timezone时区配置是修正时区错误TZ变量仅当前命令/会话否临时跨时区显示3. 时间运算让date帮你算加减法和时间差3.1 -d参数一个被严重低估的宝藏date的-d参数可以解析一个时间表达式然后输出格式化后的结果。这是我在写自动化脚本时最喜欢的特性因为它能直接处理昨天下周30天前这类自然语言级别的需求。看几个实际例子# 显示昨天 $ date -d yesterday %F # 显示30天前的日期 $ date -d -30 days %F # 显示7天后的日期 $ date -d 7 days %F # 显示下周一 $ date -d next monday %F # 显示本月最后一天 $ date -d $(date %Y%m01) 1 month -1 day %F最后那个写法稍微有点绕但原理很简单先拼出这个月的1号然后加1个月得到下个月1号再减1天就得到本月最后一天。这种组合表达式GNU date是支持的Debian/Ubuntu、CentOS/RHEL这些都跑GNU coreutils基本都兼容。如果服务器上装的是busybox或者其他精简版date可能不支持这些自然语言表达式。我在嵌入式设备上遇到过多次这个问题报错信息通常就是invalid date。这种环境下只能用笨办法把时间转成秒数自己加减86400秒再转回来。$ date -d $(( $(date %s) - 86400 )) %F这条命令先取当前时间的Unix秒数减去8640024小时的秒数再用-d 秒数的方式转成日期字符串。虽然看着麻烦但胜在通用。3.2 计算时间差秒数才是硬通货脚本里经常需要统计一段操作的耗时最朴素可靠的方法就是用%s秒数start$(date %s) # 中间执行一些耗时操作 sleep 5 end$(date %s) cost$((end - start)) echo 耗时 ${cost} 秒只要把%s这个时间戳理解为自1970年以来的秒数很多时间计算都会变得特别清爽。比如判断一个文件是否超过7天没更新可以先算当前秒数减去文件的mtime秒数now$(date %s) file_time$(stat -c %Y /var/log/app.log) diff$(( (now - file_time) / 86400 )) if [ $diff -gt 7 ]; then echo 日志文件已经 $diff 天没有更新了 fi这里我用stat -c %Y拿到文件的最后修改时间戳date %s拿到当前时间戳两者相减再除以86400得到天数。用这种方式处理时间比较比直接比较字符串格式的日期要可靠得多因为格式稍微一乱字符串排序就不可信了。3.3 时间戳与反向解析拿秒数还原时间有时候我们从数据库或配置里拿到的是一个Unix时间戳比如1734658245人眼根本看不出来这是什么时候。这时候用date反向解析$ date -d 1734658245 %F %T 2024-12-20 10:30:45我在分析应用日志时经常遇到这种场景程序只记录了毫秒级时间戳我得先换算成可读时间再去和错误日志做比对。一条命令搞定效率高很多$ date -d 1734658245 %F %T如果时间戳带毫秒需要先去掉毫秒部分或者用小数点精度$ date -d 1734658245.123 %F %T.%N不过说实话日常排查问题我都是先取整秒毫秒一般只在性能分析时才看。输出纳秒的%N用得也少除非你确实在做高精度的基准测试。4. 系统管理实战date在日志、备份、计划任务里的常规应用4.1 日志文件按日期轮转一个很常见的需求每天生成一个独立的日志文件方便查找和清理。手动写的话可以这样LOG_FILE/var/log/app_$(date %Y%m%d).log然后你的程序往这个文件写内容第二天就会因为日期变了、文件名也跟着变自然生成一个新文件。这样做的好处是日志清理可以做成这样# 删除5天前的日志文件 find /var/log -name app_*.log -mtime 5 -delete这里mtime按文件修改时间匹配由于日志文件的名字和修改时间天然一致清理逻辑非常清晰。我见过不少新手会把日期写死在配置里结果日志永远只有一个文件越来越庞大等发现时已经占用几十GB磁盘。养成用date动态生成日志名的习惯能省掉很多运维麻烦。4.2 备份脚本里的时间戳防止覆盖的关键备份脚本是这个道理最典型的应用场景。不使用时间戳的备份脚本长这样tar czf /backup/etc.tar.gz /etc这个脚本有个致命问题每天跑一次今天的备份会直接覆盖昨天万一昨天是好的、今天是坏的你根本没有回退的机会。稍微改进一下backup_date$(date %Y%m%d_%H%M%S) tar czf /backup/etc_${backup_date}.tar.gz /etc这样就保证每次备份生成的都是独立文件。配合find清理旧备份find /backup -name etc_*.tar.gz -mtime 30 -delete这招在做数据库逻辑备份时尤其救命。我曾经在凌晨2点的crontab任务里遇到过备份脚本执行到一半系统崩溃第二天早上才发现昨晚的备份文件没生成因为文件名里带时间戳前后几天的备份都在损失可控。换成不带时间戳的覆盖式备份那天就真的全没了。4.3 date、crontab与%转义问题crontab里直接用date命令时很多新手会被%号坑吐。看这个例子我想把任务日志按分钟归档*/5 * * * * echo time is $(date %F_%T) /tmp/time.log如果你直接把这个写进crontab大概率会出错或得到奇怪的结果。原因在于crontab默认情况下%是特殊字符会被解释成换行符。解决办法是给%加反斜杠转义*/5 * * * * echo time is $(date \%F_\%T) /tmp/time.log或者更干净的做法把date命令单独抽到一个脚本文件里在脚本里正常写%crontab只调用脚本。我个人的习惯就是后者因为脚本里不用考虑这些转义读起来也直观以后要加逻辑也不至于在crontab里改得乱七八糟。另外crontab里的date还有个隐含坑它用的是当前shell环境里的时区设置。如果你在crontab文件头里没设置TZ不同发行版的行为可能不一样。稳健的做法是在脚本开头写上export TZAsia/Shanghai或者直接依赖系统时区统一确保timedatectl里设置的是预期的区域。5. date命令那些反直觉的坑5.1 系统时间与硬件时间打架这个坑我在2.2里简单提过这里说一个具体排查案例。有次项目组反馈说一台数据库服务器每天凌晨4点重启后时间总会自己跳回昨天。我排查的时候先跑了date看到系统时间是对的又跑hwclock -r看硬件时间才发现硬件时钟停留在两天前的值。重启时内核从硬件时钟读时间就把系统时间带偏了。问题根因就是之前有人直接date -s改了系统时间但没有执行hwclock --systohc同步到硬件时钟。长时间断电后电池电路又让硬件时钟本身产生了偏差于是一重启就暴露了。解决办法很简单先把硬件时钟校准$ sudo hwclock --systohc然后建议启用NTP时间同步避免时间长期漂移$ sudo timedatectl set-ntp true如果你在公司内网、没有外网的NTP服务可以在内网架一台NTP服务器或者用业务系统里已有的时间源。5.2 时区写在环境变量里造成的诡异局面还有一个容易被忽略的坑当TZ环境变量被设置成奇怪的值时date输出会异常。比如某次我排查一个用户现场脚本里只要一执行date输出的时区就是UTC8但系统的timedatectl明明显示Asia/Shanghai。查到最后发现是/etc/profile里有段陈年旧代码导出了TZUTC-8。这里要特别说明一个反直觉的点POSIX风格的TZ里UTC-8反而代表的是UTC8因为POSIX时区定义的符号和日常直觉是反的正数表示西区负数表示东区。所以看到TZ的值是负数不代表就是东八区。这背后的深水太深建议别折腾直接用Asia/Shanghai这种Olson数据库的时区名更不容易出错。排查环境变量型时区问题的命令是$ echo $TZ $ env | grep TZ如果发现有输出再看它是从哪个配置文件加载的$ grep TZ /etc/profile /etc/bash.bashrc ~/.bashrc ~/.profile 2/dev/null找到后把错误导出删掉重新登录shell就正常了。5.3 脚本里调用date时常见的其他坑再补充几个我在跨平台、跨环境时遇到的细节问题。第一个是date -d这个参数在macOS的BSD date里不存在在Solaris和一些老Unix里也未必支持。如果你写的脚本要在Linux和macOS之间来回跑就要考虑兼容写法一种是用date -v-1d这种macOS专用参数另一种是干脆统一用python3 -c来做时间运算或者用date %s自行算术。我在团队里会约定所有要跨平台的脚本一律采用纯秒数运算不依赖-d的自然语言解析。第二个是格式化字符串里如果没有用双引号包裹在部分shell的某些场景下会触发历史扩展导致命令被替换成奇怪内容。这个在交互式shell里按!开头的时候最容易踩但脚本里为了保险还是养成熟练加引号的习惯。第三个是关于date的%N虽然能输出纳秒但如果脚本里多次调用date %s%N存在极低的重复概率在高并发下生成唯一ID并不可靠。你要真拿它当随机数来源是会出事儿的。唯一ID用uuidgen或/proc/sys/kernel/random/uuid更合适。Time management is one of those things that seems trivial until it bites you. 我在实际运维中观察到的经验是date命令的很多坑并不在于date本身而在于我们对时间的理解不够系统。系统时钟、硬件时钟、时区、UTC偏移、Unix时间戳这些概念搞明白了date命令的所有参数就都是具体工具而已不会再有什么神秘感。最后分享一个小技巧我在每台服务器上都习惯放一个简单的环境检查脚本里面第一行就是date %F %T %z %Z登录后先执行它确认时间和时区正确再去做其他操作这个习惯帮我提前发现过好几次时区漂移问题属于性价比极高的几秒钟。
