Skip to main content
F
f4u_corsair
Participant
May 14, 2010
Question

Issue with PARSEDATETIME(), odd Year difference

  • May 14, 2010
  • 2 replies
  • 724 views

I'ev been having an odd issue trying to convert a long string format for a date and it is showing up 10 years eaarlier.  Not sure if this is something to do with the decade or what.  I even threw it into the Parser script in the LiveDocs and it comes up wrong or at least not what I want.

The date comes from CFDIRECTORY datelastmodified.  I need to compare it to another date using datediff() so I can show only files no older than 90 days.

Here is the date as I put it in.

ParseDateTime Example

The expression "Wed May 05 09:30:42 EDT 2010" is a valid date

The parsed date/time is: {ts '2000-05-05 09:30:42'}

Enter an expression, and discover if it can be evaluated to a date value.

I tried more normal date strings with 2010 and they work.  Is it the format I am putting in?  WED? and EDT?  Are they causing the issue?

    This topic has been closed for replies.

    2 replies

    D
    Dan_Bracuk
    Inspiring
    May 14, 2010

    When I run this:

    <cfdump var="#ParseDateTime('14-May-10 01:04 PM')#">

    I get this

    {ts '2010-05-14 13:04:00'}

    Having said that, if the date is coming from a cfdirectory tag you already have a date object.  What are you trying to parse?

    -
    -__cfSearching__-
    Inspiring
    May 14, 2010

    Having said that, if the date is coming from a cfdirectory

    tag you already have a date object. 

    Are you sure? I could be wrong, but I thought it was technically a String.

    A
    Adam Cameron.
    Inspiring
    May 14, 2010

    Having said that, if the date is coming from a cfdirectory

    tag you already have a date object. 

    Are you sure? I could be wrong, but I thought it was technically a String.

    I was about to say the same thing, but I checked first. On both CF8 & CF9, the column comes back as a date.

    I'm guessing it was back in the days of CFMX7 or previous that it came back in some string, formatted in an awkward way that needed to be jigged about before it would parse.

    I had a look at the OPs issue.  I'm fairly confident it's a bug in parseDateTime().  It recognises all the other datetime parts, other than the DDD which it seems to ignore (and, obviously, the YYYY which it just buggers-up).  If you change any of the rest of them, you see the appropriate bit in the output changing.

    I'd raise it as a bug.

    I'd also not be trying to parse a string formatted like that as a date in the first place (even before I found out it wouldn't work).  Given it seems to be of a fairly predictable format, I'd just extract the relevant bits with a regex and rebuild the date from that, using createDateTime() with the individual components.

    --

    Adam

    BKBK
    Community Expert
    BKBKCommunity Expert
    Community Expert
    May 14, 2010

    You will find that, if you use the following as string parameter for parseDatetime,

    Wed May 05 09:30:42 EDT 2010
    Wed May 05 09:30:42 EDT 2001
    Wed May 05 09:30:42 1900

    Wed May 05 09:30:42

    you will get the same result, namely, {ts '2000-05-05 09:30:42'}

    I think what confuses Coldfusion is the fact that the year is at the end. Coldfusion's string-to-date interpretation is quite relaxed, forgiving and general. That is what enables it to guess the date-time value of a wide variety of  strings. You should expect the interpretation to be wide off the mark in certain cases.

    In your case, for example, the best position for the year is right after the day value. To obtain the correct datetime, consider the string as a list having one blank space as delimiter, then insert the year in the 4th position of the list. Something like this:

    <cfset dateModified ="Wed May 05 09:30:42 2010">
    <cfset yearModified = listLast(dateModified," ")>
    <cfset correcteddate = listInsertAt(dateModified,4,yearModified, " ")>

    <cfoutput>#parsedatetime(correcteddate)#</cfoutput>

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices