每个系统，会定义出不同概念的时间。同一个概念时间，在不同系统中，可能会有不同的称谓。而同一个称谓，在不同系统中，也可能指向实际不同的概念。
金融系统对时间的处理远比日常生活复杂。一笔跨境汇款从发起到账可能需要跨越多个时区、多个节假日；一笔债券的利息计算需要精确到小数天数；一次股票交易的交割日期取决于所在市场的结算规则。理解金融系统中的时间概念，是设计可靠金融软件的基础。
定义：金融市场开放交易的日期。
核心特点：
典型示例：
| 市场 | 交易时间 | 备注 |
|---|---|---|
| A股 | 周一至周五 9:30-15:00 | 法定节假日休市 |
| 港股 | 周一至周五 9:30-16:00 | 与A股略有差异 |
| 美股 | 周一至周五 9:30-16:00 (ET) | 夏令时/冬令时切换 |
| 外汇 | 周一至周五 24 小时连续 | 全球接力交易 |
| 加密货币 | 7×24 小时 | 无传统休市概念 |
⚠️ 踩坑记录：曾遇到系统按自然日判断"今天是否交易日"，结果在国庆长假期间允许交易，导致订单进入交易所被拒。必须依赖权威交易日历数据源，而非自行计算。
定义：银行或机构正常运营的日期。
与交易日的关键区别：
计算规则：
工作日 = 日历日 - 周末 - 法定节假日
💡 内部约定：在我们的系统中，工作日以央行公布的"银行工作日历"为准，而非交易所日历。两者差异主要体现在春节、国庆等长假期间——银行间市场可能比交易所提前恢复运营。
定义：连续的日历天数，不区分工作日/节假日。
主要用途：
与工作日对比示例：
假设周五发起一笔7天期限的业务：
⚠️ 踩坑记录：早期系统中存款期限"7天"按自然日计算，但客户理解是"7个工作日"，引发投诉。后改为明确标注"7个自然日"或"7个工作日"。
定义：资金或资产实际划转生效的日期。
常见别名：结算日、交割日、生效日、Settlement Date
计算方式：
⚠️ 关键注意：T 通常指交易日，不是自然日。T+1 遇到周末或节假日需要顺延。
不同市场的起息规则：
| 市场/产品 | 起息规则 | 说明 |
|---|---|---|
| A股现货 | T+1 | 卖出资金T+1可用，T+2可取 |
| 港股 | T+2 | 交收周期较长 |
| 外汇即期 | T+2 | 标准交割日 |
| 外汇远期 | T+N（约定） | 按合约约定 |
| 大额存单 | T+0 | 通常当日起息 |
| 同业拆借 | T+0 / T+1 | 视品种而定 |
💡 项目案例：在设计外汇交易系统时，曾遇到"T+2"规则在周三交易后跨越周末变成实际4个自然日的情况。系统在展示"预计到账时间"时，必须向用户展示实际日历日期，而非简单的"T+2"字样。
定义：金融工具（存款、贷款、债券）到期的日期。
与起息日的关系：
到期日 = 起息日 + 期限
期限计算方式：
到期日调整规则：
⚠️ 踩坑记录：债券到期日计算曾使用简单日期加法（LocalDate.plusMonths），结果遇到2月28日起息、3个月到期的情况，在闰年与非闰年产生不同结果。后改用金融日期计算库（如 Joda-Time 的 BusinessDateCalculator）。
定义：证券或资产实际完成交割的日期。
常见周期：
| 资产类型 | 交割周期 | 说明 |
|---|---|---|
| A股股票 | T+1 | 卖出股票资金T+1到账 |
| 港股 | T+2 | 交收周期较长 |
| 美股 | T+1 (2024年起) | 此前为T+2，2024年5月缩短 |
| 外汇现货 | T+2 | 标准交割日 |
| 外汇T+0 | T+0 | 部分平台提供的超短期交易 |
| 债券 | T+0 或 T+1 | 视市场和品种 |
| 期货 | T+0 (日内) | 期货实行每日无负债结算 |
💡 深度分析：2024年美股将结算周期从T+2缩短为T+1，这一变化影响深远：
- 降低了交易对手风险敞口
- 减少了保证金占用时间
- 但要求券商和清算系统的处理能力提升
- 对跨境投资者的汇率风险窗口也有影响
金融系统必须处理复杂的节假日规则：
| 规则 | 说明 | 应用场景 |
|---|---|---|
| 顺延 | 到期日遇节假日顺延至下一工作日 | 贷款到期、债券兑付（最常用） |
| 提前 | 部分合约可能提前至前一工作日 | 特定衍生品合约 |
| 不调整 | 按自然日计算，不区分节假日 | 部分计息场景、合同期限 |
| ** modified following** | 顺延但不超过当月最后一天 | 外汇远期、利率互换 |
| ** preceding** | 提前至前一工作日 | 特定结构化产品 |
💡 最佳实践：节假日处理不能硬编码。应维护可配置的节假日表，支持：
- 多市场节假日（中国、美国、欧洲、香港等）
- 动态更新（临时休市通知）
- 层级继承（如"全球节假日 > 市场节假日 > 产品节假日"）
计息基准决定了利息计算中"一年有多少天"和"计息期间有多少天"。
| 方法 | 说明 | 计算公式 | 应用场景 |
|---|---|---|---|
| ACT/360 | 实际天数/360 | 利息 = 本金 × 利率 × 实际天数/360 | 美元货币市场、LIBOR |
| ACT/365 | 实际天数/365 | 利息 = 本金 × 利率 × 实际天数/365 | 英镑、港币市场 |
| 30/360 | 每月30天/每年360天 | 利息 = 本金 × 利率 × (30×月差+天数差)/360 | 美国公司债、MBS |
| ACT/ACT | 实际天数/实际年天数 | 利息 = 本金 × 利率 × 实际天数/当年实际天数 | 国债、精确计息 |
| 30E/360 | 欧洲版30/360 | 月末统一按30日 | 欧洲债券 |
| NL/365 | 实际天数(不含2月29日)/365 | 闰年2月29日不计息 | 部分欧洲市场 |
⚠️ 踩坑记录：曾遇到美元贷款使用 ACT/360，而客户系统按 ACT/365 计算，导致利息差异。差异虽小（约0.14%），但在大额贷款（数亿美元）上，利息差额可达数万美元。必须在合同中明确计息基准，并在系统间对接时进行术语对齐。
计息基准选择的影响示例：
假设本金 1,000,000 美元，年利率 5%，计息期间 90 天：
| 计息基准 | 计算 | 利息 |
|---|---|---|
| ACT/360 | 1,000,000 × 5% × 90/360 | 12,500 |
| ACT/365 | 1,000,000 × 5% × 90/365 | 12,328.77 |
| 30/360 | 1,000,000 × 5% × 90/360 | 12,500 |
差异：ACT/360 比 ACT/365 多产生 171.23 美元利息。
| 业务类型 | 常见截止时间 | 说明 | 影响因素 |
|---|---|---|---|
| 大额支付 | 17:00 | 央行大额支付系统 (HVPS) | 央行系统运营时间 |
| 小额支付 | 7×24 小时 | 小额支付系统 (BEPS) | 可7×24小时运行 |
| 跨境汇款 | 15:00-16:00 | 各银行不同 | SWIFT 报文截止时间 |
| 证券交易 | 15:00 | A股收盘时间 | 交易所交易时间 |
| 外汇交易 | 16:00-17:00 | 各银行不同 | 银行内部清算安排 |
| 基金申购 | 15:00 | 按当日净值 | 基金公司 cutoff |
| 同业拆借 | 11:00-12:00 | 货币市场惯例 | 流动性管理需要 |
💡 深度分析：截止时间的设定涉及多方博弈：
- 对银行：较早的 cutoff 降低运营风险，但可能流失客户
- 对客户：希望 cutoff 越晚越好，增加操作灵活性
- 对系统： cutoff 后进入批处理，需要预留足够处理时间
- 对监管：要求 cutoff 后交易不能"回溯"到当日
⚠️ 踩坑记录：某系统 cutoff 时间配置为"17:00"，但未考虑夏令时切换。在夏令时期间，系统按 UTC 计算，导致 cutoff 实际变为"16:00"，引发客户投诉。后改为存储时区信息，使用"America/New_York"等 Olson 时区标识。
跨境支付涉及多个时区，产生复杂的时间协调问题：
核心挑战：
典型场景：
假设中国企业向美国供应商付款：
总耗时：可能 2-3 个工作日，即使使用"当日"服务。
💡 项目案例：在设计跨境支付系统时，我们引入了"预计到账时间"计算引擎：
- 输入：付款币种、收款币种、付款行、收款行、发起时间
- 处理：查询各时区 RTGS 开放时间、中间行列表、SWIFT 路由
- 输出：预计到账时间范围（如"预计北京时间次日下午到账"）
- 挑战：中间行信息不透明，实际时间可能有偏差
跨境支付的节假日处理尤为复杂：
典型冲突：
系统设计要点：
⚠️ 踩坑记录：某年伊斯兰斋月期间，系统未考虑中东合作伙伴的工作时间缩短（部分银行仅工作 4 小时），导致批量汇款延迟。后增加"合作伙伴工作时间"配置项。
核心原则：
2024-03-15T09:30:00+08:00）推荐存储结构：
public class FinancialDate {
private LocalDate date; // 日期部分
private DateType type; // 类型：TRADING_DAY / WORKING_DAY / CALENDAR_DAY
private ZoneId zone; // 时区
private String calendarId; // 关联的日历ID
private boolean isHoliday; // 是否节假日
private LocalDateTime createdAt; // 记录创建时间（UTC）
}
💡 内部约定：在我们的系统中，数据库字段命名规范：
xxx_date：纯日期（LocalDate），无时区xxx_time：日期时间（LocalDateTime），需配合时区字段xxx_at：UTC 时间戳（Instant），无时区歧义xxx_tz：时区标识（如 "Asia/Shanghai"）
推荐架构：
// 日期计算服务接口
public interface DateCalculationService {
// 计算起息日
LocalDate calculateValueDate(
LocalDate tradeDate, // 交易日
int settlementCycle, // T+N 的 N
String calendarId, // 日历标识
DateRollConvention rollConvention // 调整规则
);
// 计算到期日
LocalDate calculateMaturityDate(
LocalDate valueDate,
Tenor tenor, // 期限：如 3M, 1Y
String calendarId,
DateRollConvention rollConvention
);
// 计算工作日差
int calculateWorkingDays(
LocalDate start,
LocalDate end,
String calendarId
);
// 判断是否交易日
boolean isTradingDay(
LocalDate date,
String marketId
);
}
示例：计算起息日
// 示例：计算起息日
LocalDate valueDate = tradingDayCalculator
.addDays(tradeDate, settlementCycle) // T+N
.adjustForHolidays(holidayCalendar); // 节假日调整
// 更完整的示例
LocalDate valueDate = dateCalcService
.calculateValueDate(
tradeDate, // 2024-03-15（周五）
2, // T+2
"CNY-CNAS", // 中国外汇交易中心日历
DateRollConvention.MODIFIED_FOLLOWING // 调整规则
);
// 结果：2024-03-19（周二，跨越周末）
💡 最佳实践：日期计算必须集中管理，禁止各业务自行实现。推荐引入成熟的金融日期计算库：
- Java：Joda-Time + 自定义日历，或 Strata (OpenGamma)
- Python：QuantLib, pandas-market-calendars
- C#：NodaTime, QLNet
推荐配置项：
# 节假日配置
holidays:
calendars:
- id: "CNY-CNAS" # 中国外汇交易中心
region: "CN"
source: "CNAS" # 中国外汇交易中心发布
updateFrequency: "DAILY"
- id: "USD-FED" # 美联储
region: "US"
source: "FEDERAL_RESERVE"
- id: "HKD-HKEX" # 香港交易所
region: "HK"
source: "HKEX"
# 结算周期配置
settlement:
rules:
- productType: "FX_SPOT"
currencyPair: "*/*"
cycle: 2 # T+2
calendar: "FX-Common"
- productType: "EQUITY"
market: "SSE" # 上交所
cycle: 1 # T+1
calendar: "CNY-CNAS"
- productType: "EQUITY"
market: "HKEX" # 港交所
cycle: 2 # T+2
calendar: "HKD-HKEX"
# 截止时间配置
cutoff:
rules:
- businessType: "LARGE_VALUE_PAYMENT"
currency: "CNY"
time: "17:00"
timezone: "Asia/Shanghai"
- businessType: "CROSS_BORDER_REMITTANCE"
currency: "USD"
time: "15:00"
timezone: "America/New_York"
note: "各银行实际时间可能不同"
💡 内部约定：配置变更必须走审批流程，因为：
- 结算周期变更影响资金计划
- 截止时间变更影响客户预期
- 节假日表错误可能导致交易失败或资金损失
必须覆盖的场景：
| 场景 | 测试要点 |
|---|---|
| 跨周末 | T+1 周五交易，确认下周一而非周六起息 |
| 长假 | 国庆长假前交易，确认节后首个工作日起息 |
| 闰年 | 2月29日交易，确认日期计算正确 |
| 时区切换 | 夏令时切换日交易，确认 cutoff 时间正确 |
| 多市场 | 涉及中美两地的交易，确认双方节假日都处理 |
| 年末 | 12月31日交易，确认跨年日期计算 |
| 月末 | 30/360 计息，确认月末日期处理 |
| 中文 | 英文 | 常见别名 | 说明 |
|---|---|---|---|
| 交易日 | Trading Day | Business Day, Work Day | 市场开放交易的日期 |
| 起息日 | Value Date | Effective Date, Settlement Date | 资金实际划转生效日 |
| 到期日 | Maturity Date | Expiry Date, Due Date | 金融工具到期日 |
| 工作日 | Working Day | Business Day, Banking Day | 银行/机构运营日 |
| 自然日 | Calendar Day | Natural Day | 连续日历天数 |
| 交割日 | Settlement Date | Delivery Date | 资产实际交割日 |
| 计息基准 | Day Count Convention | - | 利息计算天数规则 |
| 截止时间 | Cut-off Time | Deadline | 业务受理截止时点 |
| 顺延 | Roll Forward | Modified Following | 遇节假日顺延 |
| 提前 | Roll Backward | Preceding | 遇节假日提前 |
💡 永远不要假设时间概念是通用的。必须在文档中明确定义每个字段的时间类型（交易日/自然日/工作日），并在跨系统对接时进行术语对齐。
** checklist **：