Come far funzionare DateCompare() in ColdFusion 10?

Question

Sto utilizzando CF10 con l'ultimo livello di aggiornamento su Windows in Pacific Standard Time. Ho bisogno di una combinazione di datecompare() che restituisce 0, ma io non riesco a farlo a comportarsi ogni dal momento che Adobe ha deciso di 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> 

USCITA:

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 

sto tirando fuori i miei capelli.

Answer 1

(troppo lungo per i commenti)

ho fatto qualche scavare con CF11, sulla base dei commenti del blog. Da quanto ho potuto vedere, il motivo per il primo confronto ha esito negativo è che, anche se le prime due date sono simili:

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

... a causa delle differenze di fuso orario, internamente gli oggetti rappresentano un punto diverso nel tempo. Questo è il motivo DateCompare() non riesce a restituire 0. (Il terzo confronto fallisce per lo stesso motivo.)

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

Avviso se si confronta lastModifiedUTC alla data originale (locale), funziona come previsto? Nonostante i diversi fusi orari, entrambi gli oggetti rappresentano ancora lo stesso punto nel tempo internamente:

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

Curiosamente, il secondo confronto non riesce inoltre a restituire 0, nonostante il fatto che entrambi gli oggetti sembrano avere lo stesso tempo e tempo zona. Tuttavia, se si osservano i valori di tempo interni, i millisecondi differiscono. I millisecondi del valore POP sono sempre zero. DatePart riporta lo stesso risultato. Il tipo di ha senso, poiché la data POP è stata creata analizzando una stringa che non contiene millisecondi. Tuttavia, ciò non spiega perché DateTimeFormat mostri i millisecondi come diversi da zero.

Il secondo confronto non restituisce 0 perché le due date hanno valori millisecondi diversi. A differenza della data del file, la data POP è stata creata analizzando una stringa che non contiene millisecondi, in modo che la parte della data sia sempre zero. Poiché dateCompare() esegue un confronto completo (compresi i millisecondi) le due date non sono uguali.

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

Tuttavia, su una nota positiva, questo significa che il confronto funziona se si salta i millisecondi e confrontare solo fino alla "seconda", cioè dateCompare(date1, date2, "s"):

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

Per inciso, io non sono certo perché Adobe ha scelto di cambiare il comportamento di qualcosa di così importante come le date UTC. Sfortunatamente, non so che c'è molto che puoi fare al riguardo a parte le opzioni menzionate nei commenti del blog a) Cambia il fuso orario di jvm o b) crea la tua versione di dateConvert e usa quella.

Boy what a mess ....