(评论太长)

根据博客评论，我对 CF11 进行了一些挖掘.据我所知，初始比较失败的原因是虽然前两个日期看起来相似:

I did some digging with CF11, based on the blog comments. From what I could tell, the reason the initial comparison fails is that although the first two dates look similar:

// code
lastModifiedUTC    : #DateTimeFormat(lastModifiedUTC, "yyyy-mm-dd HH:nn:ss.L zzz")#
lastModifiedUTC2   : #DateTimeFormat(lastModifiedUTC2, "yyyy-mm-dd HH:nn:ss.L zzz")#
// output
lastModifiedUTC    : 2015-09-13 19:51:46.219 UTC
lastModifiedUTC2   : 2015-09-13 19:51:46.219 PDT

...由于时区差异，对象在内部表示不同的时间点.这就是为什么 dateCompare() 无法返回 0 的原因.(第三次比较失败的原因相同.)

... due to time zone differences, internally the objects represent a different point in time. That is why dateCompare() fails to return 0. (The third comparison fails for the same reason.)

// code
lastModifiedUTC              : #lastModifiedUTC.getTime()#
lastModifiedUTC2             : #lastModifiedUTC2.getTime()#
// output
lastModifiedUTC              : 1442173906219
lastModifiedUTC2             : 1442199106219

请注意，如果您将 lastModifiedUTC 与原始(本地)日期进行比较，它会按预期工作吗?尽管时区不同，但两个对象在内部仍然表示相同的时间点:

Notice if you compare lastModifiedUTC to the original (local) date, it works as expected? Despite the different time zones, both objects still represent the same point in time internally:

// code
dateCompare             : #dateCompare(lastModifiedUTC, lastModified)#  
lastModifiedUTC         : #lastModifiedUTC.getTime()#
lastModified            : #lastModified.getTime()#
lastModifiedUTC         : #DateTimeFormat(lastModifiedUTC, "yyyy-mm-dd HH:nn:ss.L zzz")#
lastModified            : #DateTimeFormat(lastModified, "yyyy-mm-dd HH:nn:ss.L zzz")#

// output
dateCompare             : 0  
lastModifiedUTC         : 1442173906219
lastModified            : 1442173906219
lastModifiedUTC         : 2015-09-13 19:51:46.219 UTC
lastModified            : 2015-09-13 12:51:46.219 PDT

奇怪的是，第二个比较也未能返回 0，尽管这两个对象似乎具有相同的时间和时区.但是，如果您查看内部时间值，则毫秒会有所不同.POP 值的毫秒数始终为零.DatePart 报告相同的结果.那种 是有道理的，因为 POP 日期是通过解析不包含毫秒的字符串创建的.然而，这并不能解释为什么 DateTimeFormat 将毫秒显示为非零.

Curiously, the second comparison also fails to return 0, despite the fact that both objects seem to have the same time and time zone. However, if you look at the internal time values the milliseconds differ. The milliseconds of the POP value are always zero. DatePart reports the same result. That sort of makes sense, since the POP date was created by parsing a string which does not contain milliseconds. Yet that does not explain why DateTimeFormat shows the milliseconds as non-zero.

第二次比较失败返回 0，因为两个日期的毫秒值不同.与文件日期不同，POP 日期是通过解析不包含毫秒的字符串创建的，因此日期部分始终为零.由于 dateCompare() 执行完整比较(包括毫秒)，因此两个日期不相等.

The second comparison fails to return 0 because the two dates have different millisecond values. Unlike the file date, the POP date was created by parsing a string that does not contain milliseconds, so that date part is always zero. Since dateCompare() performs a full comparison (including milliseconds) the two dates are not equal.

// code
lastModifiedUTC                         : #DateTimeFormat(lastModifiedUTC, "yyyy-mm-dd HH:nn:ss.L zzz")#
parseLastModifiedHttpTimePOP            : #DateTimeFormat(parseLastModifiedHttpTimePOP, "yyyy-mm-dd HH:nn:ss.L zzz")#
lastModifiedUTC                         : #lastModifiedUTC.getTime()#
parseLastModifiedHttpTimePOP            : #parseLastModifiedHttpTimePOP.getTime()#
datePart(lastModifiedUTC)               : #datePart("l", lastModifiedUTC)#
datePart(parseLastModifiedHttpTimePOP)  : #datePart("l", parseLastModifiedHttpTimePOP)#

// output
lastModifiedUTC                         : 2015-09-13 19:51:46.219 UTC
parseLastModifiedHttpTimePOP            : 2015-09-13 19:51:46.0   UTC
lastModifiedUTC                         : 1442173906219
parseLastModifiedHttpTimePOP            : 1442173906000
datePart(lastModifiedUTC)               : 219
datePart(parseLastModifiedHttpTimePOP)  : 0

但是，请注意，这意味着如果您跳过毫秒并且只比较秒"即 dateCompare(date1, date2, "s")，则比较有效::

However, on a good note, that means the comparison works if you skip the milliseconds and only compare down to the "second" ie dateCompare(date1, date2, "s"):

// code
DateCompare(lastModifiedUTC, parseLastModifiedHttpTimePOP, "s") : #DateCompare(lastModifiedUTC, parseLastModifiedHttpTimePOP, "s")#
// output
DateCompare(lastModifiedUTC, parseLastModifiedHttpTimePOP, "s") : 0

顺便说一句，我不确定 Adob​​e 为何选择更改像 UTC 日期这样关键的行为.不幸的是，除了博客中提到的选项之外，我不知道您可以做很多事情评论 a) 更改 jvm 时区或 b) 创建您自己的 dateConvert 版本并改用它.

As an aside, I am not sure why Adobe chose to change the behavior of something as critical as UTC dates .. Unfortunately, I do not know that there is much you can do about it other than the options mentioned in the blog comments a) Change the jvm time zone or b) create your own version of dateConvert and use that instead.

孩子，真是一团糟……