dateDiff возвращает неправильное значение

У меня есть переменная с именем date1, которая содержит объект даты/времени ColdFusion, сгенерированный с использованием parseDateTime. Когда я выгружаю переменную, я получаю {ts '2014-12-20 15:46:57'}.

У меня есть еще одна переменная с именем date2, которая содержит другой объект даты/времени ColdFusion, сгенерированный dateConvert("local2utc",now()). Когда я выгружаю переменную, я получаю {ts '2014-12-20 15:49:40'}.

Но когда я делаю dateDiff("s",date1,date2), я получаю -21436, что слишком много секунд. Кто-нибудь может объяснить, почему это происходит? Я думаю, что это может быть проблема с часовым поясом, но я не могу понять это.

Репродукционный код

<cfset dtString = "Saturday, December 20, 2014 05:07:30 PM">

<cfset dtObject = parseDateTime(dtString)>

<cfdump var="#dtObject#">

<cfset utcNow = dateConvert("local2utc",now())>

<br><br><cfdump var="#utcNow#">

<br><br><cfdump var="#dateDiff("s",dtObject,utcNow)#">

coldfusion coldfusion-11
person Michael    schedule 20.12.2014    source источник
comment
Можете ли вы опубликовать репродукцию, которую мы можем скопировать, чтобы воссоздать проблему?   -  person Matt Busche    schedule 20.12.2014
comment
Нет, мы не можем комментировать так или иначе, не видя репродукции, демонстрирующей то, что вы видите. Пожалуйста, прочитайте это и ссылки на документы: blog.adamcameron .me/2013/09/   -  person Adam Cameron    schedule 20.12.2014
comment
Я подозреваю, что вы находитесь в TZ, который является UTC-6? Если вы погуглите базу ошибок CF (google.co.uk/search ?q=bugbase.adobe.com+dateConvert) возникло множество проблем с dateConvert(), которые, похоже, произошли в то же время, что и вы. Adobe утверждает, что исправила их, но я бы никогда не был в них так уверен. Я подозреваю, что ваша первая дата находится в вашей локальной TZ, а вторая - в UTC, поэтому вы получаете это смещение, отраженное в результатах dateAdd(). Что касается того, почему вы не видите разницы TZ в <cfdump>? Не знаю. Хотя меня это не удивляет.   -  person Adam Cameron    schedule 20.12.2014
comment
Я добавил некоторый код, который при запуске на моем сервере вызывает проблему   -  person Michael    schedule 20.12.2014
comment
Спасибо Адам. Похоже, это связано с проблемой на bugbase.adobe.com/index.cfm. ?event=bug&id=3338974. Если я сделаю <cfset utcNow = dateConvert("local2utc",now()).toString()>, проблема исчезнет.   -  person Michael    schedule 20.12.2014
comment
Один из вас, ребята, должен опубликовать ошибку (и возможную работу) в качестве ответа :)   -  person Leigh    schedule 20.12.2014
comment
@ Майкл, почему бы тебе не опубликовать ответ: ты был тем, кто разобрался с окончательными деталями. Кроме того, мы можем проголосовать за него и получить больше очков репутации.   -  person Adam Cameron    schedule 21.12.2014

Ответы (2)


arrow_upward
6
arrow_downward

Причина этой проблемы, по-видимому, связана с ошибкой, описанной на странице https://bugbase.adobe.com/index.cfm?event=bug&id=3338974.

Как описано в приведенном выше URL-адресе, «переменная, возвращаемая из DateConvert("local2Utc",now()), по-видимому, содержит смещение от локального до UTC. Когда вы используете эту переменную практически для чего угодно (включая cfqueryparam), значение, которое вы возвращаете, отличается на величину смещения (т.е. возвращается к значению, которое вы передали)».

Обходной путь, по-видимому, заключается в преобразовании даты в строку после преобразования. Я создал простую функцию-оболочку для этого следующим образом:

<cffunction name="local2utc" output="no">
    <cfargument name="date">

    <cfreturn dateConvert("local2utc",arguments.date).toString()>

</cffunction>
person Michael    schedule 21.12.2014

arrow_upward
0
arrow_downward

Еще одно исправление для этого — использовать parseDateTime.

<cfset localDate = now()>
<cfset utcDate = DateConvert("local2utc", localDate)> 
<cfset utcfix = parseDateTime(utcDate)> 

utc epoch: #DateDiff("s", "January 1 1970 00:00", utcfix)#<br>
loc epoch: #DateDiff("s", "January 1 1970 00:00", localDate)#
person bob    schedule 27.03.2018