riqi：日期查询与换算的实用指南

riqi 是什么：核心用途与适用边界

很多人第一次听到 riqi 这个名字，会下意识把它当成一个确定的网站或某个 App。这里得诚实地讲一句：这是一个含义比较模糊的名称，可能指向日期查询类的工具，也可能是某个小组件、某本台历的名字。所以这篇说明页给出的不是「它必然是什么」的断言，而是一套可核对的判断方法与使用口径——你手上那个叫 riqi 的东西，能不能对上下面说的用途，自己比一比就知道了。

从用途上看，日期类工具真正解决的无非几件事：一是把某一天翻译成人能读懂的形式，比如 2026-10-27 是星期二；二是把不同写法的日期统一成一种，让表格能排序、让系统能读；三是在公历与农历之间来回换算，尤其是生日、节气、传统节日这种场景；四是处理程序里的时间戳，把它变成看得懂的时分秒；五是做加减运算，算出相隔几天、到期是哪天。这五件事几乎覆盖了绝大多数普通人和办公场景下对日期的全部需求。

边界也得说清楚。日期换算工具做不了历法的最终裁决——农历的编排由权威历书确定，闰月出现在哪一年、某个节日落在哪一天，以公开的历法资料为准。工具也不该替你判断「哪个日期是对的」这种业务问题，比如合同起算日、工龄计算口径，这些要按合同条款或单位规定来。工具能做的是把计算过程透明化，让你看清楚它是怎么算的，然后由你自己决定是否采信。

riqi三类典型需求：不同人群拿它做什么

第一次使用 riqi：从输入到结果的完整流程

流程听起来简单，但真正卡住新手的往往不是工具本身，而是「我到底该填什么」。所以下面按顺序拆成五步，每一步都给出具体输入和预期结果，你可以照着对一遍。

1. 先确认你要解决的是哪类问题

   耗时约 10 秒 · 难度：低

   是「2026 年 10 月 27 日是星期几」这种单点查询？还是「农历九月十八对应公历哪天」这种换算？还是要「把这串 1735689600 变成时间」？三类问题对应的输入字段完全不同，先分类能避免在错误的地方填数据。经验上，新手 80% 的困惑来自把换算当成了查询。

2. 按推荐格式输入日期

   耗时约 30 秒 · 难度：低

   推荐写法是 2026-10-27 或 2026年10月27日，年份写满四位。为什么强调四位？因为 10/27/26 里的 26 到底是 2026 还是 1926，机器分不清，不同地区的月日顺序也不一样。举个可验证的例子：输入 2026-10-27，预期得到「星期二」；如果写成 27/10/2026，某些按美式月日解析的入口会读成无效日期并报错。

3. 选择历法与时区选项

   耗时约 20 秒 · 难度：中

   涉及农历时要明确是公历转农历还是农历转公历，遇到闰月必须勾选「闰」标记——比如 2025 年有闰六月，输入六月和闰六月是两个完全不同的结果。涉及时刻的要确认时区，东八区与 UTC 差 8 小时，这一步选错，结果会整体偏 8 小时。

4. riqi核对输出结果

   耗时约 20 秒 · 难度：低

   拿结果和手边日历对一下，重点看三处：年份对不对、星期对不对、跨月边界对不对。比如算 10 月 31 日往后 1 天，正确答案是 11 月 1 日；如果工具给出 10 月 32 日这种结果，说明它没有做月末进位，属于实现缺陷。

5. 保存结果，或者转入批量处理

   耗时约 10 秒 · 难度：低

   单条结果直接复制即可。若手上有几十上百条日期，就别一条条来，按「一行一条、统一分隔符」整理成文本或表格再批量提交，效率能提升十几倍。批量处理的具体规范在后面「批量处理多组日期」一节细讲。

riqi 日期格式识别：常见写法与自动解析逻辑

先把常见的写法摆出来。第一种是 ISO 风格的 2026-10-27，年月日从大到小，国际通用、歧义最小。第二种是中文写法 2026年10月27日，国内文档里最常见，工具一般都支持。第三种是斜杠写法 2026/10/27，Excel 和不少系统都认。第四种是点分写法 2026.10.27，日韩地区较常见。第五种就是麻烦制造者：10/27/26 或 27/10/26，既缺年份又分不清月日顺序。

自动解析的逻辑，说穿了就是「先找年份、再定月日」。如果开头或结尾是四位数字，一般能锁定年份；如果只有两位，就得靠上下文猜，猜错就可能把 2026 读成 1926。月份和日期则依赖分割符位置，斜杠写法在美式语境里默认「月/日」，在欧式语境里默认「日/月」，这就是为什么同一串 03/04/2026 在不同工具里会得出两个不同结果。

还有一类容易被忽略：带星期的写法，比如「2026 年 10 月 27 日 星期二」。星期是冗余信息，工具通常会忽略它，但如果你手输的星期和日期对不上，比如写成「2026 年 10 月 27 日 星期三」，工具不一定报错——它可能只取日期、悄悄丢掉星期。这一点需要你输入后自己核一眼。

被识别之后，工具会做哪些「纠正」

有些纠正是无害的，比如把「2026年10月27日」补全成 2026-10-27，把前导零补齐，把全角数字转半角。这些改动不改变含义，属于正常归一化。

另一些纠正就有风险了。最典型的是日期不存在时的「滚动进位」：输入 2026-02-30，有的工具会报错，有的会悄悄算成 2026-03-02。两种处理都有道理，但对用户来说，如果不提示就直接改，很容易得到一个你自己都没察觉的错误日期。所以看到结果先确认它有没有提示「已修正」，别默认它算对了。

公历与农历换算：riqi 的处理方式与注意点

农历的编排逻辑，和公历是两套体系。公历以地球绕太阳一周为基准，一年约 365.2422 天，用闰年补差；农历以月亮绕地球的朔望周期（约 29.53 天）定月，一年 12 个月只有约 354 天，比回归年少约 11 天。为了不让节气越跑越远，古人每两三年就要加一个闰月，这就是「十九年七闰」的来历。所以农历年份可能 12 个月，也可能 13 个月。

换算时要特别留意闰月。以 2025 年为例，这一年有闰六月，也就是说会出现「六月」和「闰六月」两个相邻的月份。如果你要查的是闰六月十五，却只输入了六月十五，结果会整整偏出一个月。很多对不上的情况都出在这里，不是工具算错，而是输入时把闰月漏掉了。

节气是另一个易混点。二十四节气按太阳黄经划分，本质上属于阳历体系，所以在公历上的日期相当稳定，比如清明总在 4 月 4 日至 6 日之间。它并不对应农历的固定日子。你要查「今年立冬是哪天」，用公历换算更直接；要查「农历十月十五是公历哪天」，才是农历换算的活。

子时跨日：一个容易被忽视的边界

传统历法里，一天的起点不完全等同于公历的 0 点。有的算法把 23 点后的子时算作次日，有的算作当日，这个差异会导致晚间出生的日期在换算时出现一天出入。遇到生日核对这类较真的事情，建议把口径写清楚：是按公历零点切分，还是按子时切分，两者结论可能不同。

顺带说一句，农历的权威性来自历书，而不是任何一个网站。我们在这里讨论的是换算方法与常见坑，具体到某年某月某个节日究竟落在哪一天，最终应以公开发布的历法资料为准。这个态度贯穿整页：能给出方法的地方给方法，需要权威裁定的地方就明确告诉你去找权威。

时间戳与日期互转：riqi 在开发与记账场景的实操

时间戳的存在，是为了让机器有个统一的时间标尺，不受时区和格式影响。Unix 纪元定在 1970-01-01 00:00:00 UTC，之后每过一秒，数字加一。所以 10 位的时间戳大约覆盖到 2286 年，13 位则是把秒乘以 1000 得到毫秒，精度更高，前端和数据库里更常见。

实操上第一步是数量位。拿到 1735689600，数一下是 10 位，属于秒级；拿到 1735689600000，13 位，属于毫秒级。如果拿 10 位的数按毫秒解析，会得到一个 1970 年附近的日期；反过来把 13 位按秒解析，会跑到几万年以后。这两个错误在对账时特别常见，因为不同系统导出的量级并不统一。

第二步是定时区。同一个时间戳，在东八区显示为 2025-01-01 08:00 前后，在 UTC 显示为 2025-01-01 00:00 前后，差的正好 8 小时。记账时如果发现流水时间和银行 App 差 8 小时，八成是时区没对上，而不是数据本身有错。

riqi记账场景里的具体做法

拿到一份带时间戳的流水，先看表头有没有说明量级，没有的话抽一行和已知时间对一下。比如某笔交易你记得是 1 月 1 日上午发生的，它对应的数字是 10 位、以 1735 开头，就能确认是秒级。确认之后整列按同一规则换算，避免逐条试错。

开发场景里还要注意「零时区存储、本地时区展示」这个惯例。数据库里存 UTC 时间戳，界面上按用户所在地转成本地时间，这是通行做法。自己写脚本时如果两边都用了本地时间，跨时区协作就会出现莫名其妙的时间漂移。

日期加减与间隔计算：riqi 在排期与倒计时里的用法

自然日和工作日是两回事。从 10 月 27 日往后推 5 个自然日，是 11 月 1 日；往后推 5 个工作日，则要跳过 10 月 31 日和 11 月 1 日这个周末，落到 11 月 3 日。同样的「5 天」，结论差了两天，排期里这就是能不能按时交付的问题。

做间隔计算时，还要分清「含首日」还是「不含首日」。从 10 月 27 日到 10 月 30 日，如果两头都算，是 4 天；只算一头，是 3 天。合同里的「起算日」「到期日」通常有明确约定，按约定口径来，别默认工具的天数就是业务天数。

倒计时场景更直接。离某个截止日还有多少天，把今天和目标日输进去就行。需要注意的是，如果跨越了月末、年末，人工心算容易出错。比如从 12 月 28 日到次年 1 月 3 日，跨年那一步很多人会漏掉 31 日这天，算出来少一天。交给工具算，这类跨年边界反而最稳。

工作日计算的两个现实变量

第一是调休。法定节假日与调休安排每年公布，不是固定规律，工具如果只按「周一到周五」算工作日，遇到调休就会偏。第二是行业差异。有的单位周六也上班，有的实行大小周，通用的「工作日」定义未必适用。所以想把工作日算准，先把你们单位的休息日规则告诉工具，或者干脆按自然日算好再人工校正。

还有一个常被问到的点：间隔计算要不要考虑时区。如果两端都是纯日期、不带具体时刻，一般不受时区影响；一旦带上了时分秒，跨时区就可能差出一天。这就是为什么纯日期相减更稳定，涉及时刻就要统一到同一时区再算。

批量处理多组日期：riqi 的表格与文本导入技巧

先说文本导入。用记事本整理日期时，一行放一条最稳妥，别在同一行塞多个日期。分隔符建议用英文逗号或制表符，别用中文顿号、中文逗号，因为全角符号在很多解析器里会被当成普通字符，导致整行读不出来。整理完先抽三五行试跑，通过了再全量提交。

再说表格导入。Excel 里最坑的是「日期格式的单元格」和「文本格式的单元格」看着一样、其实不同。同一个 2026-10-27，在日期格式下是序列值，在文本格式下是字符串，导出后可能变成一串数字。处理方法是在导入前统一转成文本，或者导出为 CSV 并确认年份是四位数。

常见的报错有三类。第一类「无法解析」，多半是分隔符或格式不一致；第二类「部分成功」，说明是个别行有问题，重点查空行、合并单元格、单元格内多余空格；第三类「结果全错但没报错」，通常是把月日顺序读反了，比如把 03/04 读成了 4 月 3 日而非 3 月 4 日。

批量处理有个容易被低估的好处：一致性。人工逐条输入时，第一行写 2026-10-27，第二十行可能就写成 2026年10月27号，格式一乱，后期排序和筛选全是麻烦。批量导入强迫你先把数据洗干净，后面省下的是成倍的时间。

结果对不上？riqi 五类高频误差排查清单

第一类，年份误读。两位年份是重灾区，26 到底是 2026 还是 1926，取决于工具采用什么世纪基准。排查方法很直接：把年份补成四位再算一次，结果稳定了就说明是这个问题。

第二类，时区偏差。特征是结果整体差整数小时，通常就是 8 小时。排查方法是把输入的时间戳或日期明确标注东八区，再换算一次，看差值是否消失。记账对账时尤其常见。

第三类，闰年边界。2024 年是闰年，2 月有 29 日；2026 年不是闰年，2 月只有 28 日。输入 2026-02-29 这种不存在的日期，有的工具报错、有的悄悄滚到 3 月 1 日。排查方法是先查那一年是不是闰年，再看工具的处理策略。

第四类，月日顺序。03/04/2026 在不同设定下可能是 3 月 4 日，也可能是 4 月 3 日。排查方法是看结果里的月份对不对，对不上就基本确认了。

第五类，闰月遗漏。农历换算专属问题，输入六月却想要闰六月，结果会差一个月。排查方法是在农历输入框里确认有没有勾选「闰」。

riqi 与其他日期工具怎么选：四个对比维度

准确性是第一位的。判断依据很简单：拿几个已知答案的边界案例去试，比如 2024-02-29 是否有效、2025 年闰六月是否存在、2026 年 10 月 27 日是不是星期二。能全部答对的，准确性问题不大。

易用性看输入方式。有的工具必须点日历控件选，有的直接打字就认。日常只是查个星期几，打字更快；批量处理，表格导入更合适。两者没有绝对优劣，看你更常做哪类事。

隐私与离线能力，往往被忽视，却最能区分工具的定位。凡是需要你把日期提交到服务器才算的，都涉及数据离开本机；能离线运行的，数据不出设备。涉及生日、合同金额这类敏感组合信息时，离线方案更让人放心。

riqi 自身方案的推荐榜单

下面把日期处理的几种常见用法排一排，方便你按需取用。这里的排序依据是使用频率与覆盖场景的广度，不涉及任何外部产品对比。

安全与隐私：输入日期数据时该注意什么

很多人觉得日期不算隐私，可一旦和别的信息组合，性质就变了。生日加姓名可以指向具体个人，合同日期加金额可以暴露交易内容，就诊日期加科室能推测健康状况。所以判断风险，看的不是日期本身，而是它周围还带着什么。

实操上有个简单原则：能本地处理的就别上传。纯换算类需求，如果手上工具支持离线，优先用离线的。必须在线时，只输入必要的日期，别顺手把整行表格连姓名一起粘进去。

另外留意页面的传输方式。正规站点应该走 HTTPS，数据在传输过程中有加密。如果你在地址栏看到的是未加密的连接，又在填个人信息，那就不太合适了。

最后是留存意识。有些工具会把输入历史存在本地，方便下次再查，这本身是好事，但在公共电脑上用完记得清掉。家庭共用设备上同理，涉及私密纪念日、纪念日的安排，做完就清理一下。

riqi 搜索全景：大家都在搜什么

把真实的相关搜索词按意图归组，能看出需求其实很集中。下面这两组数据来自搜索引擎的相关搜索统计，口径为近 30 天，仅供了解整体需求分布。

数据来源：搜索引擎相关搜索，近 30 天，仅供参考。

最新专题时间线：这阵子在补哪些内容

日期这类内容，谈不上天天有大新闻，但确实有不少细节值得一条条补。下面是我们最近在整理的专题，按时间倒序排，你可以挑感兴趣的先看。

1. 2026-10-26跨年倒计时为什么总少算一天？把 12 月到次年 1 月的边界场景拆开看，找出心算最容易漏掉的那一天。
2. 2026-10-22时间戳 10 位和 13 位怎么一眼分清给了三个快速数量位的小技巧，对账前看一眼就够。
3. 2026-10-182026 年还剩多少天？顺手算一下从 10 月 27 日算到年末，顺带讲了年度计划的倒排方法。
4. 2026-10-14农历闰月到底怎么标才不出错以近年有闰月的年份为例，说明输入时漏勾会差出多少。
5. 2026-10-09Excel 日期变数字的三种救法文本、序列值、导出格式，三种成因对应三种处理。
6. 2026-10-03工作日计算遇上调休怎么办把调休从工具里拆出来人工校正，反而更可靠。

新手使用指南与避坑须知

第一次接触日期工具，最怕的不是不会用，而是用错了还浑然不觉。下面这几条是从实际反馈里攒出来的，逐条看一遍能少走不少弯路。

riqi四步走完第一次使用

1. 先拿已知答案的日期试一条

   耗时约 30 秒

   比如输入 2026-10-27，看它是不是告诉你星期二。这一步是校验，别跳过。

2. 再试一个边界日期

   耗时约 30 秒

   输入 2024-02-29，看它是否认可；输入 2026-02-29，看它是否报错。两个结果对得上，说明闰年处理没问题。

3. 最后再处理你的真实数据

   耗时约 1 分钟

   校验通过后，把统一格式的数据喂进去，出错概率会低很多。

riqi识别低质页面的几个信号

一是结果前后矛盾，同一输入两次给出不同答案；二是页面塞满弹窗和跳转，正文却只有一两行；三是要求你填一堆和日期无关的个人信息才能看结果。碰到这类页面，直接关掉是最省事的。

设备安全方面，别从陌生链接打开来历不明的在线工具，尤其别在公共电脑上保持登录状态。手机上如果用到相关应用，从正规应用商店获取，权限只给必要的。

背后是谁在整理这些日期资料

日期这件事看着小，涉及面却不窄。我们是一个小而稳定的编辑组，长期关注格式、历法与时间戳相关的实用问题。

沈默 · 主笔

长期整理日期格式与历法换算资料，偏好把复杂规则拆成能照着做的步骤。负责本页大部分正文的撰写与核对。

林工 · 技术校对

负责时间戳与跨时区部分的复核，习惯用边界案例验证结论，尤其关注秒级毫秒级混用的问题。

riqi若宁 · 资料核验

负责把每个结论落到可查的依据上，遇到说不准的地方会明确标注待核，不做硬性断言。

以上为用于说明内容分工的虚拟角色，不代表真实履历或机构。

我们在哪些环节打磨过

riqi 常见疑问集中解答：格式、时区与结果不一致

下面这些问题来自实际使用中最常被问到的场景，答案尽量写细，遇到类似情况可以对着排查。

还有几个零散但常被问到的点

有人问「2026 年 10 月 27 日是当年第几天」，答案是第 300 天（平年，1 月到 9 月累计 273 天，加 27 天）。也有人问「闰年一共有多少个」，公历规则是四年一闰、百年不闰、四百年再闰，按这个规则，每 400 年里有 97 个闰年。这类具体数字用工具算一次就能验证，比背规则更直观。

还有人关心「跨年日期怎么输」。答案很简单，年份照实写就行，2026-12-31 和 2027-01-01 各写各的，不需要特殊标记。工具会自动识别跨年，反而是人工心算容易在这类边界上出错。

提示：以上内容用于说明日期处理方法，涉及法定节假日、历法发布与业务计算口径的事项，请以主管部门公布与你的合同约定为准。

读者评论：用过之后大家都在说这些

riqi 术语小词典：日期处理里的关键概念

这些词在看文档、跟人沟通时经常出现，用大白话过一遍，后面遇到就不容易卡壳。

闰年

公历里比平年多一天的那一年，2 月有 29 日，全年 366 天。规则是四年一闰、百年不闰、四百年再闰。所以 2000 年是闰年，1900 年不是。

时区

地球上按经度划分的时间区域，全球共 24 个标准时区，相邻时区差 1 小时。中国全境统一用东八区，和 UTC 差 8 小时。

纪元

计算时间的起点。计算机里的 Unix 纪元定在 1970-01-01 00:00:00 UTC，时间戳都是从这一刻开始累加。公历的纪元则通常指公元 1 年。

朔望月

月亮从朔到下一次朔的周期，约 29.53 天。农历的月份长度就是按它来的，大月 30 天、小月 29 天。

闰月

农历为了补齐与回归年的差而插入的月份。有闰月的年份是 13 个月，比如 2025 年有闰六月。输入时不标「闰」就会差一个月。

时间戳

从纪元起经过的秒数或毫秒数，10 位通常表示秒，13 位通常表示毫秒。它不受时区影响，是机器之间传递时间的通用方式。

这些定义力求准确，但历法规则细节较多，遇到需要严格裁定的场合，仍建议以公开的历法资料为准。

把 riqi 融进日常工作流：几个能长期坚持的习惯

工具用一阵子容易忘，真正能坚持下来的，往往是把它变成流程里的一环。下面这几个习惯，成本都不高。

riqi建一个固定格式的日期模板

在常用的文档或表格里，预先建好一个模板，日期字段统一用 2026-10-27 这种写法，备注字段写清口径，比如「工作日」「含首日」。以后每次填都照着来，省掉临场纠结。

把常用换算做成快捷方式

如果每天都做同一类换算，比如固定查某个时区的时间戳，可以把步骤记在一张便签上，或者收藏对应页面。减少重复操作，出错概率也跟着降。

每周固定核对一次

排期类工作建议每周固定时间核对一次，把本周的节点与真实日期再对一遍。单次只要几分钟，但能提前发现排期里的偏差，比到期才发现要轻松得多。

这些习惯没什么技术含量，贵在稳定。日期处理这件事，真正省时间的从来不是某个神兵利器，而是把规则固定下来、少做重复判断。

把日期问题理清楚，从这里开始

查询、换算、时间戳、加减与核对，这篇里能说的都说了。剩下的就是动手试一条，拿已知答案的日期校验一遍，心里就有底了。

看看 riqi App　关于我们