ColdFusion/Java中America/New_York时区时间转UTC方案咨询

现有代码正确性判断 #

你的实现逻辑是正确的：

• 输入的标准ISO格式本地时间字符串通过LocalDateTime.parse()解析没有问题，不需要额外自定义格式化器。
• 通过ZoneId.getRules().getOffset(ldt)动态获取纽约时区对应时间点的实际偏移，能自动适配冬令时/夏令时的偏移切换，不存在写死偏移的错误。
• 后续通过withOffsetSameInstant做瞬时时间转换再取UTC本地时间的计算逻辑完全准确，结果和预期一致。

更简洁的推荐写法 #

你当前的实现手动完成了时区偏移的获取逻辑，实际上java.time原生提供了更直接的时区绑定API，不需要手动调用时区规则取偏移，代码更简洁易维护，中间对象更少，执行效率和原实现基本无差异（java.time类都是不可变轻量对象，这点性能差完全可以忽略），出错概率更低。
优化后代码如下：

var validatedDateTime = '2022-06-29T14:30:00';

LocalDateTime = createObject('java', 'java.time.LocalDateTime');
ZoneId = createObject('java', 'java.time.ZoneId');
ZoneOffset = createObject('java', 'java.time.ZoneOffset');

ldt = LocalDateTime.parse(validatedDateTime);
nyZone = ZoneId.of('America/New_York');
// 直接将本地时间绑定到纽约时区，自动处理夏令时、时间间隙/重叠的规则
nyZonedTime = ldt.atZone(nyZone);
// 直接转换为UTC时区的瞬时时间，提取本地日期时间结果
utcDateTime = nyZonedTime.withZoneSameInstant(ZoneOffset.UTC).toLocalDateTime();

额外提示 #

• 你选择直接调用Java 8+的java.time（JSR-310）包实现时间处理的方向完全正确，这套API比ColdFusion原生时间函数、旧版Java的Date/Calendar类设计更严谨，线程安全，没有隐式时区偏移的坑，性能也更优。
• 如果后续需要处理非标准格式的时间字符串，只需要额外创建DateTimeFormatter实例传入解析方法即可，当前场景不需要额外配置。
• 不要用网上流传的旧版java.util.Calendar实现方案，那些方案需要手动处理时区偏移、夏令时逻辑，非常容易出计算错误。

内容的提问来源于stack exchange，提问作者Nick Petrie