FedEx预计时间窗不是交付事件：EDTW的起止、地区与缺值条件

一个运输系统返回两个时间戳，未必是在报告两次已经发生的配送。FedEx的Estimated Delivery Time Window，简称EDTW，是依据所请求地点的历史配送数据给出的预计时间范围。[1] 它描述预测何时可能送达，与实际包裹已经交付的事件时间不同。

文档为这项对象列出两个端点：estimatedDeliveryTimeWindow中的window/begins是预计范围开始的日期时间，window/ends是范围结束的日期时间。[1] 两项共同构成窗口，不能分别改写成已开始配送、已完成配送。页面给出的日期只是文档示例，本文没有向API提交跟踪号，也没有取得任何真实包裹的当次时间。

预测依据本身带有地点条件。来源说，EDTW使用客户所请求地点已完成配送的历史数据，并提醒预计时间可能因某些配送地点而变化。[1] 因而，一份时间窗是带背景的预测表达，不是一项脱离地点的统一运输时限。本文不由历史样本推导某次实际配送必然落在范围内。

地域和服务范围必须按原页列表保留。本次读取的文档列出目的地美国、加拿大、比利时、德国与荷兰，服务包括FedEx Express、FedEx Ground及FedEx Home Delivery。[1] 页面入口虽位于en-cy目录，不能据这个路径再加进塞浦路斯，也不能扩成全球全部服务都会提供同样窗口。资料入口名称与正文能力清单，应各按自己的范围理解。

没有窗口同样不宜立刻诊断成查询失败。官方明确说，不是所有跟踪号都会返回EDTW，原因涉及不同包裹处理情境，例如预约、特定日期或晚间配送，以及改为Hold at Location取件等。[1] 这些是文档列举的可能背景，不是一看到缺值就能确定其中某个原因。本篇没有安排、改变任何配送或取件方式。

相邻的配送计划信息还有另一组字段。delayDetail/status可表示ON_TIME、EARLY或DELAYED；延误情形还可能附带WEATHER类型及SNOW子类型。[1] 状态、原因分类与更细子分类分别提供信息，而预计窗口的两个端点则提供时间范围。它们不是同一个字段，更不能把ON_TIME直接翻成Delivered。

对运输软件交接，完整描述可以分别指出取得的是预计范围、计划状态，还是具体延误原因。如果窗口没有返回，仍应照实际响应保留缺失事实，不用其他状态替它补出一个时间；若有预计窗口，也不以此证明收件人已经收到货物。这些是依据开发文档作出的对象区分，没有核验真实承运记录。

本文只采用Basic Integrated Visibility文档的EDTW及相邻delay说明，首次发布日期未知。未采用签名获取、个人信息、通知发送、运费或合同内容，也不承诺交期、货物保护或运输安全。预测记录能够说明系统怎样表达预计范围，实际交付仍需要相应事件证据。

资料：[1] https://developer.fedex.com/api/en-cy/catalog/track/v1/docs.html