How to make DateCompare () behave in ColdFusion 10?

Question

I use CF10 with the latest update level for Windows in the standard Pacific standard. I need a combination of datecompare() that returns 0, but I can't make it behave since Adobe decided to change the behavior of DateConvert() and datecompare()

 <cfset filePath = getBaseTemplatePath()> <cfset fileinfo = getFileInfo(filePath)> <cfset lastModified = fileinfo.lastModified> <cfset lastModifiedUTC = dateConvert("local2utc", lastModified)> <cfset lastModifiedUTC2 = dateAdd("s", getTimezoneInfo().UtcTotalOffset, lastModified)> <cfset lastModifiedHttpTime = getHttpTimeString(lastModified)> <cfset parseLastModifiedHttpTimeSTD = parseDateTime(lastModifiedHttpTime)> <cfset parseLastModifiedHttpTimePOP = parseDateTime(lastModifiedHttpTime, "pop")> <cfoutput> <pre> lastModified (local) : #datetimeformat(lastModified, 'long')# lastModifiedUTC : #datetimeformat(lastModifiedUTC, 'long')# lastModifiedUTC2 : #datetimeformat(lastModifiedUTC2, 'long')# datecompareLmUTC : #dateCompare(lastModifiedUTC, lastModifiedUTC2)# //wtf lastModifiedHttpTime : #lastModifiedHttpTime# parseLastModifiedHttpTimeSTD : #datetimeformat(parseLastModifiedHttpTimeSTD, 'long')# parseLastModifiedHttpTimePOP : #datetimeformat(parseLastModifiedHttpTimePOP, 'long')# I need a datecompare() combination that returns 0 ------------------------------------------------ DateCompare(lastModifiedUTC, parseLastModifiedHttpTimePOP) : #DateCompare(lastModifiedUTC, parseLastModifiedHttpTimePOP)# DateCompare(lastModifiedUTC2, parseLastModifiedHttpTimePOP) : #DateCompare(lastModifiedUTC2, parseLastModifiedHttpTimePOP)# CF Version : #server.coldfusion.productVersion#, update level: #server.coldfusion.updatelevel# </pre> </cfoutput> 

OUTPUT:

 lastModified (local) : September 11, 2015 7:10:23 PM PDT lastModifiedUTC : September 12, 2015 2:10:23 AM UTC lastModifiedUTC2 : September 15, 2015 4:58:22 PM PDT datecompareLmUTC : -1 //wtf lastModifiedHttpTime : Sat, 12 Sep 2015 02:10:23 GMT parseLastModifiedHttpTimeSTD : September 12, 2015 2:10:23 AM PDT parseLastModifiedHttpTimePOP : September 12, 2015 2:10:23 AM UTC I need a datecompare() combination that returns 0 ------------------------------------------------ DateCompare(lastModifiedUTC, parseLastModifiedHttpTimePOP) : 1 DateCompare(lastModifiedUTC2, parseLastModifiedHttpTimePOP) : 1 CF Version : 10,0,17,295085, update level: 17 

I am pulling my hair out.

Answer 1

(too long for comments)

I did a bit of work with CF11 based on blog comments. From what I could say, the reason for the failed initial comparison is that although the first two dates look the same:

 // 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 

... due to differences in time zones, inside objects represent a different point in time. This is why dateCompare () does not return 0. (The third comparison fails for the same reason.)

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

Please note, if you are comparing lastModifiedUTC with the original (local) date, does it work as expected? Despite different time zones, both objects still represent the same point in time inside:

 // 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 

It is curious that the second comparison also does not return 0, despite the fact that both objects have the same time and time zone. However, if you look at the internal values ​​of time, the milliseconds are different. Milliseconds POP values ​​are always zero. DatePart reports the same result. This approach makes sense because the POP date was created by parsing a string that does not contain milliseconds. However, this does not explain why DateTimeFormat shows milliseconds as nonzero.

The second comparison does not 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 this date is always zero. Since dateCompare () does 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 

However, on a good note, this means that the comparison works if you miss the milliseconds and compare only with the "second", i.e. dateCompare(date1, date2, "s") :

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

Aside, I'm not sure why Adobe decided to change the behavior of something as important as UTC dates. Unfortunately, I don’t know that you can do a lot, except for the comments mentioned on the blog a) Change the jvm time zone or b) create your own version of dateConvert and use this instead.

Boy what a mess ....