Jak uzyskać DateCompare(), aby zachowywać się w ColdFusion 10?

Question

Używam CF10 z najnowszym poziomem aktualizacji w systemie Windows w czasie Pacyfiku. Muszę datecompare() kombinację, która zwraca 0, ale nie mogę zmusić go do zachowują się każdy od Adobe postanowił 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> 

WYJŚCIE:

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 

jestem ciągnięcie moich włosów.

Answer 1

(zbyt długo na komentarze)

zrobiłem kilka kopanie z CF11, w oparciu o komentarze na blogu. Z tego co mogę powiedzieć, powodem początkowe porównanie nie jest to, że choć pierwsze dwa terminy wyglądają podobnie:

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

... ze względu na różnice stref czasowych, wewnętrznie obiekty reprezentują inny punkt w czasie. Dlatego dateCompare() nie zwróci 0. (trzecie porównanie nie powiedzie się z tego samego powodu.)

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

Zawiadomienie jeśli porównać lastModifiedUTC do pierwotnej daty (lokalnym), to działa zgodnie z oczekiwaniami? Pomimo różnych strefach czasowych, oba obiekty nadal reprezentują ten sam punkt w czasie wewnętrznie:

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

Co ciekawe, drugie porównanie również nie zwraca 0, pomimo faktu, że oba obiekty wydają się mieć ten sam czas i czas strefa. Jeśli jednak spojrzysz na wartości czasu wewnętrznego, liczba milisekund różni się. Liczba milisekund wartości POP zawsze wynosi zero. DatePart zgłasza ten sam wynik. Ten rodzaj ma sens, ponieważ data POP została utworzona przez parsowanie ciąg, który nie zawiera milisekund. Jednak to nie wyjaśnia, dlaczego DateTimeFormat pokazuje milisekundy jako niezerowe.

Drugie porównanie nie zwróci 0, ponieważ dwie daty mają różne milisekundy. W przeciwieństwie do daty pliku, data POP została utworzona przez przeanalizowanie łańcucha, który nie zawiera milisekund, więc ta część daty zawsze ma wartość zero. Ponieważ metoda dateCompare() wykonuje pełne porównanie (w tym milisekundy), dwie daty nie są równe.

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

jednak na dobre noty, co oznacza, że ​​porównanie działa jeśli pominąć milisekund i tylko porównać do „drugi”, czyli dateCompare(date1, date2, "s"):

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

Tak na marginesie, nie jestem jasne, dlaczego Adobe zdecydował się zmienić zachowanie czegoś tak krytycznego jak daty UTC. Niestety, nie wiem, czy jest coś, co można z tym zrobić poza opcjami wymienionymi w komentarzach na blogu a) Zmień strefę czasową jvm lub b) stwórz własną wersję dateConvert i użyj jej zamiast tego.

Chłopak, co za bałagan ...