我需要用CICS ABSTIME填充PIC S9(15) COMP-3变量。 （我相信这是自1900年年初以来经过的毫秒数）
我的输入在fomat YYYY-MM-DD hh:mm:ss.mmmmmm中。这表示CET时区（阿姆斯特丹）中的时间戳，并且遵循夏时制（'DST'）。
我已经找到解决方案的一部分：
EXEC CICS CONVERTTIME
DATESTRING ('Tuesday, 09-Oct-07 04:57:43 GMT')
ABSTIME (WS-TIMESTAMP)
END-EXEC
ABSTIME +003400898263000中的结果
但是CONVERTTIME只能处理4种日期格式类型（RFC 1123，RFC 3339，RFC 850，ASCtime），而这两种格式都不能同时处理时区和DST看到：https://www.ibm.com/support/knowledgecenter/SSGMCP_5.4.0/reference/commands-api/dfhp4_converttime.html
哪个是将日期（包括时区和DST转换为ABSTIME的正确的Cobol（/ CICS）方法？
我同意Hogstrom的看法，夏/冬（夏令时/标准）的时移已经改变，并且可能会随着将来的变化而改变，因此从根本上讲，这是一个由数据驱动的问题，需要解决和重新解决。如果您关心leap秒，那将是一个类似的问题。如果您关心的是最近的历史时间，那么荷兰有这些有趣的时区偏移量（此处为标准时间）：
[1909年5月1日至1937年7月1日：UTC + 0h19m32.13s（是的，很严重）
[1937年7月1日至1940年5月16日：UTC + 0h20m
荷兰从1916年到1945年观察到夏令时，从1946年到1976年不再观察它，然后从1977年开始再次观察它。很可能荷兰在当年已应用DST。 （我不确定那部分内容。）欧盟目前正在就协调时区以及可能摆脱夏/冬时移问题进行积极的辩论，因此有必要提前计划，避免嵌入类似Y2K的做法问题纳入解决方案。无论您做什么，都想尝试使代码成为将来的合理证明。
好的，在这种背景下，如果与时间相关的数据的提供者坚持提供阿姆斯特丹的本地时间而不是帮助您使用UTC，我认为您应该拥有某种输入文件，参数列表或表，定义如何将阿姆斯特丹当地时间转换为UTC。如果/如果显示的日期/时间早于1977年1月1日，则可能会引发错误。如果您的应用程序支持某种形式的跟踪或日志记录，则我会写出有关本地时间到UTC时间转换规则集最后一次的信息。更新。我还要在文件/表/规则集中添加一些日期代码注释/版本信息。首先以编程方式应用在该输入文件中定义的规则，然后将UTC传递到上面的代码中。如果想（以一种好的方式）花哨的话，可以在BRMS中定义时区/ DST规则，例如z / OS的IBM Operational Decision Manager（ODM）（如果已有的话）。 ），然后从COBOL调用BRMS。
[另一种可能性是使用java.time从本地时区/ DST转换为UTC。本文介绍了如何完成此操作：
https://www.baeldung.com/java-daylight-savings
当然，您可以在CICS中运行Java程序（的确很好），并且Java Standard Edition是基本z / OS操作系统的一部分，已包含并免费提供了支持。 （尽管自由配置文件也是CICS Transaction Server的一部分，但它很简单，您不需要Liberty。）
这里的危险是，如果Java发行商（在这种情况下为IBM）或更可能是系统操作员未将Java运行时保持最新，那么您的程序可能会在任何时候将过时的转换规则从本地应用到UTC决定将来更改规则。因此，我很不情愿地喜欢基于输入规则文件/表/参数列表的方法。
确定，什么输入文件/表/参数列表？好吧，IANA的时区数据库将是一个非常不错的选择：
https://data.iana.org/time-zones/tz-link.html
您的代码可能只需要处理该数据库的一小部分，但是作为“真理之源”，它是一个很好的数据库。