tracker issue : CF-3972534

select a category, or use search below
(searches all categories and all time range)

DateTime conversion to UTC seems to have a bug

| View in Tracker

Status/Resolution/Reason: Closed/Won't Fix/

Reporter/Name(from Bugbase): H God / H God (H God)

Created: 04/20/2015

Components: General Server

Versions: 11.0

Failure Type:

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Major / All users will encounter

Locale/System: ALL / Win 2008 Server R2 64 bit

Vote Count: 0

Problem Description: coldfusion reports nowUTC from nowUTC = dateconvert('local2utc",now()) correctly, but when using nowUTC in datedediff, the result is based on now() instead of nowUTC .... 

Steps to Reproduce: see example in test configuration. and attached screenshot of the result here in my test. I am based in amsterdam and here is a time difference of 2hrs with UTC.

Actual Result: dateconvert("local2utc") seems not make any difference in the datediff result.

Expected Result:there should be difference between the two datediff's.

Any Workarounds:

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3972534

External Customer Info:
External Company:  
External Customer Name: H
External Customer Email:  
External Test Config: My Hardware and Environment details:

<!--- Test script: --->


	tst.lowDT = createdatetime(2015,04,20,09,20,17); = now();

	tst.nowUTC = DateConvert("LOCAL2UTC",now());

	tst.diff_with_now = datediff('n',tst.lowDT,;

	tst.diff_with_nowUTC = theTimediff('n',tst.lowDT,tst.nowUTC);


	<cfdump var="#tst#" label="datediff direct">



It seems that there are two layers in which dates are calculated. and with datconvert, the result is not updated in one of the layers ...
Comment by External U.
7763 | April 20, 2015 07:06:01 AM GMT
The test script is stated not correctly. please use: <cfscript> tst.lowDT = createdatetime(2015,04,20,09,20,17); = now(); tst.nowUTC = DateConvert("LOCAL2UTC",now()); tst.diff_with_now = datediff('n',tst.lowDT,; tst.diff_with_nowUTC = datediff('n',tst.lowDT,tst.nowUTC); writedump(var="#tst#",label="datediff direct"); </cfscript>
Comment by External U.
7764 | April 20, 2015 07:08:12 AM GMT
For Amsterdam (time difference with UTC = 2 hr): expected: tst.diff_with_now - tst.diff_with_nowUTC = => 2hr but I get back => 0hr ???
Comment by External U.
7765 | May 11, 2015 06:56:54 AM GMT
DateConvert does not change the date. It changes only the timezone. The timestamp (or time since epoch) still remains the same. So datediff before and after DateConvert will not have any change.
Comment by Himavanth R.
7766 | September 23, 2015 12:43:52 AM GMT
Dear Himavanth , This cannot be seriously your answer? 1:Are you not mistaken here.. When I print a converted day-time I get what I expect; When I transform the datetime into a createodbcdatetime() string, I still get what I expect. Why do some functions work with the internal daytime and some don't? 2:If this working with internal date-time variables in stead of the display day-time; this has changed since coldfusion9. Why didn't we hear about this very elementary change in how to work with day-times? I still persist in my opinion that it is wrong to keep working with an internal value because you can nowhere see if a variable uses its internal value or its display value!!! That makes no sense... Please your answer on this. I hope as soon as possible and not 5 months later!!! yours sincerely.
Comment by External U.
7767 | October 01, 2015 10:50:46 AM GMT
Dear God (wait.. is that ok?), Firstly, let me give you some background. DateConvert('local2utc",now()) means convert the date from local timezone to utc timezone. Previous versions of CF had a bug in that instead of actually changing the timezone, the actual timestamp itself was changed. Because of this there were a lot of bugs around the handling and conversion of times near DST change windows. We fixed this by not actually changing the timestamp in DateConvert but changing the TimeZone. Now a DateDiff compares the timestamps which is why the dates are equal before and after DateConvert Now coming to your question... Agreed there should not be a different time internally than what is shown externally (as string representation). I say there is a bug here in the representation of datetime. The TZ should also be shown (especially if it's not local TZ). But including that would break a lot of existing applications. Also agreed that earlier applications which were depending on the incorrect conversion in DateConvert broke after the DST bug fix. This is now being reviewed.
Comment by Himavanth R.
7768 | October 04, 2015 11:12:23 PM GMT
Hi Himavanth, I've added a comment on CF-3347145. Thanks!, -Aaron
Comment by External U.
7769 | October 05, 2015 02:39:35 AM GMT
We reviewed this and there is little that can be done here for reasons explained by Hima on Oct 05,2015.
Comment by Vamseekrishna N.
7770 | October 03, 2016 12:55:18 AM GMT