KNX DPT11 的两位年份落在哪个世纪：怎样验证日期窗口

按XKNX 3.6.0的DPT11.001规则，年份码90到99映射1990到1999，00到89映射2000到2089。1989不在这一窗口中，不能靠当前年份推断世纪，也不能将89随意解释成1989。

适用版本与输入范围

依据 XKNX 维护者仓库固定标签 3.6.0 的下列源码，只实现本文明示的数据点或组值解析子集。它不是 KNX 规范全文，也不是设备互通认证；组地址与DPT应由项目点表明确提供。 本文所有输入均为原创合成数据，未接真实设备。

三字节依次是日、月和年份码

附件01 01 5A表达1990年1月1日：5A十进制90，触发加1900；1F 0C 59表达2089年12月31日：59十进制89，应加2000。程序先取日低五位、月低四位与年份低七位，再做明确世纪窗口映射。不能把常见的Unix年份偏移或BACnet加1900规则搬到这里，否则2000年之后的日期会整体落入错误世纪。

窗口边界必须单独验证

1990与2089分别卡住上下边界，能发现“90包含在哪一侧”的比较符号错误。年份码100虽占得下七位，也不是本类型允许的两位年份；程序明确拒绝，不取模100。反向编码若用户输入1989，也应报告超出支持窗口，而不是只保留89再解为2089。本程序只实现解码，正文强调反向路径同样需要范围约束，避免项目在跨世纪历史资料中静默丢失年代。

字段范围和日历有效性分两步

日1到31、月1到12只能排除部分错误，仍可能出现2月30日。示例进一步调用Python日历校验，2000年闰日通过，2001年闰日被拒绝。这是本题交付程序添加的严格日历检查，不将它冒充维护者解析器所有行为的逐字复刻。保留位是否非零也单列报告，便于工程决定是否拒收，而不是让掩码操作把原始异常彻底隐藏。

日期不包含时刻与时区

输出ISO日历字符串便于导出，但没有小时、UTC偏移或设备时间质量。若与DPT10组合，仍要约定两条电报是否来自同一时刻、缺失时怎样处理；不能因为日期合法就视为完成对时。本附件没有连接任何KNX设备，也没有验证真实工程的ETS显示策略。它限定固定版本公开实现的世纪窗口，用可复跑边界案例帮助检查日期接口，避免系统默认两位年份规则与KNX规则冲突。

下载与复跑

将输入 fixture.json与独立程序 verify.py放在同一目录，用 Python 3.12 执行 python verify.py，无需安装第三方包。程序从自身目录读取输入并写入 report.json，不要求当前终端恰好位于下载目录。也可查看本次实跑报告和复跑说明。

本次实际运行通过 5 条输入断言，包括标有“显式负例”的记录；负例以JSON字段承载，不会把下载文件本身做成损坏编码。year_code保留两位年份；date不含时区，日历有效不等于设备时钟准确。 修改输入后应同时审查期望结果，不能只改断言数字让测试变绿。

对象或字段的基础关系可回到KNX 组地址与DPT入门核对，更多接口入口在设备协议库。若需要把已确认的数据点接入展项编排，可了解SoftControl 展厅中控；具体接入能力以项目确认和实际测试为准。

一级依据

• DPTDate

来源核对日期：2026-10-24。离线结果只证明给定输入的解析或计算行为；现场兼容性、响应时间、硬件准确度和具体产品支持均未测量。