ColdFusion UTC TIME LTE проверяет время без UUTC - PullRequest
1 голос
/ 11 ноября 2019

Я потерян, я могу проверить не UTC Times и все работает. Но при конвертации в UTC Times CFIF не работает

NON UTC {ts '2019-11-10 14:59:46'} LTE {ts '2019-11-10 14:00:00'}

UTC, если {ts '2019-11-10 21:59:46'} LTE {ts '2019-11-10 21:00:00'}

Я потерян... Не могу понять это.

<cfset timenow = #Now()#>

<cfset utimenow = dateConvert("Local2UTC", timenow)>

<cfset admintime = #DateAdd("h", -1, chk.stime)#>
<cfset uadmintime = #DateAdd("h", -1, chk.utcact)#>

Время chk.stime и chk.utc правильное. в основном это время отключения часов для окна отмены.

Это созданные метки времени.

NON UTC {ts '2019-11-10 14:59:46'} LTE {ts '2019-11-10 14:00:00'}

Марки NonUTC - это метки времени без преобразований UTC.

UTC if {ts '2019-11-10 21:59:46'} LTE {ts '2019-11-10 21:00:00'} 

Марки NonUTC

<cfif timenow LTE admintime>
This one works fine...
 NON UTC {ts '2019-11-10 14:59:46'} LTE {ts '2019-11-10 14:00:00'}
 Then allow cancel
<cfelse>
This cfelse is activated properly and Can't Cancel.
 Can't Cancel
</cfif>

UTC Stamps
<cfif utimenow LTE uadmintime>
This one does not work
 UTC if {ts '2019-11-10 21:59:46'} LTE {ts '2019-11-10 21:00:00'}
 Then allow cancel
 This UTC Time does not activate properly and allows the cancel.
 Executes/Activates inside the cfif - it should not
 <cfelse>
 Can't Cancel
</cfif>

Я также пытался конвертировать, чтобы быть уверенным в ODBCTime

<cfset uadmintime = createODBCDateTime(uadmintime)>

Мне пришлось пересоздать время и сравнить этот формат. Теперь он работает как с <cfif timenow LTE admintime>, так и с DateCompare, как показано ниже. Должно быть, это проблема форматирования, из-за которой не понравилось форматирование {ts '2019-11-10 14:59:46'} LTE {ts '2019-11-10 14:00:00'}.

<cfset nctime = '#dateformat(uadmintime, "dd-MM-yyyy")# #timeformat(uadmintime, "hh:mm:ss")#'>
<cfset nutctime = '#dateformat(utimenow, "dd-MM-yyyy")# #timeformat(utimenow, "hh:mm:ss")#'>

1 Ответ

3 голосов
/ 11 ноября 2019

ColdFusion является свободно типизированным языком и может хранить значения даты / времени в различных типах данных. Стандартные сравнения, такие как eq, lte и т. Д., Сравнивают переменные разных типов, основанные на неизвестных и изменяющихся правилах, поэтому могут иметь неожиданные результаты, если CF решит преобразовать в другой тип данных. В некоторых случаях можно ожидать, что переменная будет объектом даты / времени, когда действительно это строка, которая проходит валидацию для даты. Различные версии CF, Lucee и т. Д. Могут действовать по-разному или зависеть от фактических значений.

Я рекомендую всегда , используя dateCompare() при сравнении дат ...

https://cfdocs.org/datecompare

<cfif utimenow LTE uadmintime>
    ...
</cfif>

становится

<cfif dateCompare(utimenow, uadmintime) lte 0>
    ...
</cfif>

Пример кода:

https://cffiddle.org/app/file?filepath=e3d24147-8a25-44ff-a98d-5b1e686cd619/d6115113-eead-4214-bc94-13eb7f0456f5/efad9206-b082-4940-bf5d-f4c5001ae2ec.cfm

...