关于 date-fns
date-fns 是面向 date-fns v4 及其时区包的 Agent 技能。它指导开发者根据已安装版本和时区需求修改代码,并提供针对性文档与验证步骤。
主要功能
- 01date-fns v4 日期操作指导
- 02格式化与解析建议
- 03时区和夏令时处理指导
- 04FP 模式、本地化与 TypeScript 指导
- 05迁移和验证清单
适用场景
- 01为日历计算选择 date-fns API
- 02处理 UTC 或命名 IANA 时区
- 03检查日期格式化与解析代码
- 04规划 date-fns 版本迁移
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ dobroslavradosavljevic/ skills --skill date-fns安装后在 Claude Code 中输入/date-fns确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
agents/openai.yamlreferences/format-parse.mdfp-locales-types.mdmanipulate-compare.mdmigration-pitfalls.mdsetup-core.mdsource-map.mdtimezones.md详细介绍
date-fns
将此技能用于 date-fns v4 日期计算、格式化、解析、FP 模式、本地化,以及官方时区包 @date-fns/tz / @date-fns/utc。
工作流
- 修改代码前,先检查本地环境:
- 包:
date-fns、可选的@date-fns/tz、@date-fns/utc(以及存在时的旧版date-fns-tz)。 - 版本:优先使用 date-fns ≥ 4,以获得一流的
{ in }/TZDate/UTCDate互操作支持。v3 很常见,但仅适用于本地场景,除非使用date-fns-tz。 - 时区意图:系统本地 UI、规范化为 UTC 的服务端计算,或命名的 IANA 时区(用户/场馆/总部)。
- 导入:从
"date-fns"、"date-fns/fp"、"date-fns/locale/*"、"date-fns/constants"使用具名导入。
- 包:
- 版本不明确,或工作涉及时区、Unicode 标记、SSR 或重大升级时,更新文档。从 source-map.md 开始。
- 按需查阅更深入的内容:
- 安装、导入、核心概念、Invalid Date:setup-core.md。
format/parse/parseISO、Unicode 标记:format-parse.md。- 加减/设置/边界、差值、Interval、Duration:manipulate-compare.md。
TZDate、UTCDate、tz/utc、transpose、DST、SSR:timezones.md。- FP、本地化、TypeScript:fp-locales-types.md。
- v2→v3→v4 和
date-fns-tz迁移:migration-pitfalls.md。
- 与项目已安装的主版本和现有导入风格保持一致。除非时区语义有此需要,否则不要添加
@date-fns/tz或@date-fns/utc。 - 使用类型检查和针对性测试进行验证;相关时,测试 Invalid Date、日历差值与经过时间差值,以及时区/SSR 边缘情况。
时区决策树
System-local calendar / host TZ only?
→ plain Date + date-fns
UTC-only math (server day, charts, no IANA zones)?
→ @date-fns/utc (UTCDate / UTCDateMini or { in: utc })
Named IANA zone or multi-zone product?
→ @date-fns/tz (TZDate / TZDateMini or { in: tz("…") })
Stuck on date-fns v3?
→ upgrade to v4 + official packages, or use legacy date-fns-tz until then
核心判断
- 裸用 date-fns 时采用系统本地时区,它不是 UTC 库。对于非本地日历字段,请使用
@date-fns/utc或@date-fns/tz。 - 优先使用具名导入。常量从
"date-fns/constants"导入,而不是从主导出入口导入。 - 始终先执行
isValid,再执行format——format遇到 Invalid Date 时会抛出RangeError。 - Unicode 标记:使用
yyyy-MM-dd,不要使用 Moment 风格的YYYY-MM-DD/DD(周历年 / 年中的第几天)。参见 format-parse.md。 parseISO("YYYY-MM-DD")→ 本地午夜;new Date("YYYY-MM-DD")→ UTC 午夜。不要混为一谈。- 日历日数相关问题优先使用
differenceInCalendar*;计算完整经过时间单位时使用differenceIn*。 - 对于混合时区或原始值,使用
{ in: tz("…") }或{ in: utc }固定上下文——否则,第一个对象Date/扩展类型参数会决定时区,且参数顺序可能改变日期计算结果。 new TZDate(iso, zone)≠ 旧版toZonedTime。它们表示同一时刻,但墙上时钟时间不同。墙上时钟映射使用transpose。- 在库边界处优先使用完整的
TZDate/UTCDate;Mini 变体会跳过支持时区的toString/ 本地化格式化器(可能泄漏系统时区)。 - 不要将
@date-fns/tz与第三方date-fns-tz混淆。
验证
优先使用仓库自有命令。根据相关性覆盖以下项目:
bun pm ls date-fns @date-fns/tz @date-fns/utc(迁移时也检查date-fns-tz)。- 针对
DateArg、选项类型和扩展类型返回值进行类型检查。 - 测试:有效/无效解析、Unicode 标记、日历差值与经过时间差值、反向区间、DST 春季向前/秋季向后切换、
{ in }与参数顺序的时区选择。 - 如果要格式化“今天”或本地日界线,且服务端(通常为 UTC)与客户端(本地时区)不一致,则进行 SSR/水合冒烟测试。
报告已运行和未运行的检查,以及仍然存在的版本假设。
评论
支持 Markdown