tracker issue : CF-3338974

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

DateConvert("local2Utc",now()) Breaks Other Date/Time Functions

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/Duplicate

Reporter/Name(from Bugbase): Chris Phillips / Chris Phillips (cf_chris)

Created: 09/28/2012

Components: Language, Functions

Versions: 10.0

Failure Type: Data Corruption

Found In Build/Fixed In Build: Final /

Priority/Frequency: Critical / All users will encounter

Locale/System: English / Windows 7 64-bit

Vote Count: 6

Duplicate ID:	CF-3309220

Problem Description: The variable returned from DateConvert("local2Utc",now()) seems to carry around the offset from local to UTC. When, you use that variable for just about anything (including cfqueryparam), the value you get back is off by the amount of the offset (i.e. back to the value you passed in).

Steps to Reproduce: 
1) Assign the result of "DateConvert("local2Utc",now())" to a variable.
2) Use it in any number of functions or tags that deal with "time". (e.g. DateTimeFormat, TimeFormat, CreateODBCDate, cfqueryparam)

Actual Result: Instead of UTC time, it will be back to your machines local time.
	Example:
	<cfset date = DateConvert("local2Utc",now()) />
	<p>#DateTimeFormat(date)#</p><!--- Differs by the amount of hours of offset to UTC. (Correct in CF9) --->
	<p>#CreateODBCDateTime(date)#</p><!--- Differs by the amount of hours of offset to UTC. (Correct in CF9) --->

Expected Result:
	I expect the results to match the last several version of Adobe CF.

Any Workarounds:
	Call "toString()" on the result of "DateConvert("local2Utc",now())" before it is passed into any other time related function.
	Example:
	<p>#CreateODBCDateTime(date.toString())#</p><!--- Output is correct. --->

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

Watson Bug ID:	3338974

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

Version 	ColdFusion 10,282913

Update Level 	02

Operating System 	Windows 7  

Update Level 	/I:/ColdFusion/InstanceA1/lib/updates/hf1000-3332326.jar

Attachments:

  1. September 29, 2012 00:00:00: 1_CF10DateErrors.cfm
  2. October 09, 2012 00:00:00: 2_CF10DateErrors-2.cfm

Comments:

This effects virtually ALL functionality dealing with time that I tested. Even when I passed "DateConvert('local2Utc',now())" directly to cfqueryparam, the original date was stored in the DB instead of the UTC value. My suspicion is that this could all be because the Java class that is returned from DateConvert('local2Utc',now()) changed from CF9 to CF10. It used to be "coldfusion.runtime.OleDateTime" and now it is "coldfusion.runtime.UTCOleDateTime". Also, bug CF-3323800 should be closed/merged. It only addresses one small symptom of the larger issue.
Comment by External U.
17823 | September 28, 2012 06:09:25 PM GMT
This bug caused us to create/send/store incorrect dates in the day or so that we have been running live on CF10. There is no way we will recover from this amount of corruption to our data. It has upset our customers. And now we have to roll back onto our CF9 servers until I can patch our code appropriately.
Comment by External U.
17824 | September 28, 2012 06:14:37 PM GMT
Confirmed: DateConvert("local2Utc",now()) is inconsistent with previous versions.
Vote by External U.
17834 | September 28, 2012 06:19:36 PM GMT
Confirmed here too. It seems like the result from dateConvert() is holding on to some TZ info that it shouldn't, and this manifests when it's used in other date functions. -- Adam
Vote by External U.
17835 | September 29, 2012 12:44:29 PM GMT
I have tested and confirmed the same behavior.
Vote by External U.
17836 | September 29, 2012 02:20:10 PM GMT
I hope you are aware that ParseDateTime(date,"pop") also has the same issue. It now returns an "coldfusion.runtime.UTCOleDateTime". This has caused further incorrect dates to be stored and further embarrassment to our company.
Comment by External U.
17825 | October 05, 2012 03:25:02 PM GMT
This ticket is NOT a duplicate. The other ticket only describes one symptom of a fundamental issue. Passing the result of DateConvert("local2Utc") to <cfqueryparam> is broken. I have attached "CF10DateErrors-2.cfm" for you to run. Just set the DSN variable at the top to a valid SQL Server datasource.
Comment by External U.
17826 | October 08, 2012 12:43:05 PM GMT
I confirmed this also. My work-around is putting the following line after the DateConvert: <cfset thenow = CreateDateTime(Year(thenow), Month(thenow), Day(thenow), Hour(thenow), Minute(thenow), Second(thenow))> This CORRECTLY creates a new date object that can be used properly with other date functions without reverting back to the original time. It should also continue to function upon a future hot-fix, so no need to rewrite all the code again! PLEASE fix this bug!
Vote by External U.
17837 | October 08, 2012 10:04:52 PM GMT
This should NOT be withdrawn.. It is not a duplicate and needs to be fixed!
Comment by External U.
17827 | October 08, 2012 10:05:17 PM GMT
I confirmed this also. My work-around is putting the following line after the DateConvert: <cfset thenow = CreateDateTime(Year(thenow), Month(thenow), Day(thenow), Hour(thenow), Minute(thenow), Second(thenow))> This CORRECTLY creates a new date object that can be used properly with other date functions without reverting back to the original time. It should also continue to function upon a future hot-fix, so no need to rewrite all the code again! PLEASE fix this bug!
Comment by External U.
17828 | October 08, 2012 10:06:15 PM GMT
I confirmed this issue on my fully patched CF10 (build 282913). It is preventing me from using CF10 in a production environment. This bug should be re-opened or submitted again. Please fix this!
Comment by External U.
17829 | October 15, 2012 08:13:40 AM GMT
I have tested and confirmed this issue. It's preventing me from using CF10 in a production environment.
Vote by External U.
17838 | October 15, 2012 08:16:18 AM GMT
I applied the updater 3 that came out today. It fixes the display function issues that I found. It DOES NOT fix the <cfqueryparam issue that I submitted as "CF10DateErrors-2.cfm". Either re-open this ticket or link it to one that is for <cfqueryparam not working with the new return values from DateConvert and ParseDateTime.
Comment by External U.
17830 | October 16, 2012 12:52:26 PM GMT
Happy to see this being fixed finally. Unfortunately, as you can see here (https://bugbase.adobe.com/index.cfm?event=bug&id=CF-3347145), it is NOT fully fixed. Still waiting for the final fix. I had to help a co-worker just the other day use my workaround because it is still broken.
Comment by External U.
17831 | July 15, 2013 11:46:39 AM GMT
Just ran into this issue this morning converting some code over to CF10, with a fully patched install. It's ridiculous this bug still exists!
Vote by External U.
17839 | June 16, 2014 12:01:30 PM GMT
Please fix this bug, it's still exists: dt = dateConvert("local2utc", now()); writeDump(var=[dt.getClass().getName(), dt, createODBCDateTime(dt + 0)]); When you output this code, you can see the time gets converted back into local time.
Comment by External U.
17832 | June 16, 2014 12:03:11 PM GMT
I've also noted a bug in dateDiff() as well. If you pass in datetime which is a UTCOleDateTime object and an OleDateTime object, you will end up unexpected results. Since date/times returned back from the database are always returned as OleDateTime objects, this creates a problem if your database times are all in UTC. For example, if your database returns a date/time of "2014-06-01 12:00:00" and the result of dateConvert("local2utc", now()) is "2014-06-01 12:01:00", you would expect that there is a 1 minute difference between the date/times. However, if your server is configured for EDT, the difference when running across dateDiff() would be 4 hours and 1 minute.
Comment by External U.
17833 | June 16, 2014 03:54:29 PM GMT