Please find link to ColdFusion 10 release notes here.

6 Comments to “ColdFusion 10 release notes”

  1. Aaron Neff
    Hi Hemant,

    In CF10's Release Notes, I didn't find mention this: CF10 changed the meaning of utc2local and local2utc.

    IMO, this is an important issue that deserves public input (bugbase doesn't facilitate this, since it doesn't notify commenters of new comments).

    The CF9 and CF10 documentation say:
    1) dateConvert() returns "UTC- or local-formatted time object"
    2) local2utc "Converts local time to UTC time"

    In Pre-CF10 and CF10, #1 is true. The value displayed on screen is UTC in both pre-CF10 and CF10.

    In Pre-CF10, #2 is also true. In CF10, #2 is ONLY true based on INTERPRETATION of the meaning of "Converts local time to UTC time".

    If reader interprets that as "Converts value from local time to UTC time", then #2 is untrue in CF10.


    time1 = time2 = now();
    writeOutput(dateConvert("local2utc", time1) is dateAdd("s", getTimeZoneInfo().utcTotalOffset, time2));

    When server's time zone is not UTC:
    1) above code returns Yes in Pre-CF10 and No in CF10
    2) cfqueryparam sends value as UTC in Pre-CF10 but as local in CF10
    3) serializeJSON() outputs value as UTC in Pre-CF10 but as local in CF10

    Any applications that were migrated from Pre-CF10 to CF10 are currently experiencing silent data corruption if:
    1) the server's time zone is not UTC
    2) the app uses dateConvert() on date/time values before storing/sending them or after reading/receiving them

    The proposed workaround (the JVM arg to restore CF9 behavior) doesn't seem to be of use to the users most affected by this: Shared hosting customers. Shared hosting servers are typically not in UTC time zone and shared hosting customers typically lack the required access for applying a JVM argument.

    Others have mentioned this before, but I don't see it documented yet. I just saw another bug (#3364479) filed over a month ago regarding this, but no feedback from Adobe on that ticket yet.

    Can this please be both blogged about and documented since it silently breaks migrated apps?

  2. Hemant Khandelwal
    I will ask relevant teams to investigate this.
  3. Aaron Neff
    Hi Hemant,

    Very cool, thank you for looking into it. Here is a simple workaround, if users wish to enable Pre-CF10 behavior but lack the permission/access for applying a JVM arg:

    local = now();
    utc = dateConvert("local2utc", local);
    if(SERVER.ColdFusion.ProductVersion gte 10) {
        utc = createDateTime(year(utc), month(utc), day(utc), hour(utc), minute(utc), second(utc));
        utc = dateAdd("l", timeFormat(local, "l"), utc);

    This copies the date part and time part strings into a new date/time object on CF10. The new object will have the UTC value.

  4. Aaron Neff
    Btw, I'm not suggesting that CF10's dateConvert() behavior is correct. When user wants to convert a date/time to UTC, there is the date"Convert"() function. It should do as its name suggests and convert both the string representation AND the underlying numeric value of a date/time object. Currently dateConvert() is broken b/c it now only does half of its job.

    What developers have -really- been asking for is setTimeZone()/getTimeZone().

  5. Dan G. Switzer, II
    The issue that Aaron reported here is still a problem in CF10 and now CF11. I've been bitten by this issue several times. My solution is to replace all instances of dateConvert(), with a version that always returns an OleDateTime object internally.

    The problem is, under the hoods, when CF does a date operation on an UtcOleDateTime, it ends up returning an OleDateTime object, which means you end with a time back in local time.

    Very problematic and confusing.

    There are several bugs in the Adobe bugbase for this issue.

    Really is a major pain for anyone using the dateConvert("local2utc", ....) function and expecting to be able to do date math on the value.
  6. Dan G. Switzer, II
    Just gotten bitten by this bug again, but in a new way.

    If you're using CF's implementation of ehCache in replication mode and your servers are configured for any timezone other than GMT, you will run into issues with date/times.

    For example, if you store the following value in cache:
    dateConvert("local2utc", now())

    What the all other nodes will see after synchronization is not the time in UTC, but instead the date/time stamp will be in local time.

    There's no way that's going to be the expected behavior and it makes working with timestamps in UTC (which is all we use) way more difficult than it needs to be.

    We actually had to go through all our code and replace any code using dateConvert() to use our own version which returns the timestamp as a normal date/time object, because dateConvert() just doesn't give you usable results.

Leave a Comment

Leave this field empty: