Skip to main content
A
Anonymous
November 5, 2012
Question

Bug with createTimeSpan

  • November 5, 2012
  • 1 reply
  • 729 views

Hi,

Since the daylight savings began on Sunday morning, I have been having this problem:

<cfset x = now()>

<cfset y = now() + createTimeSpan( 0, 0, 0, 0 )>

<cfset z = now() + createTimeSpan( 0, 1, 0, 0 )>

<cfoutput>

x: #timeFormat( x, "h:mm tt" )# <br />

y: #timeFormat( y, "h:mm tt" )# <br />

z: #timeFormat( z, "h:mm tt" )# <br />

</cfoutput>

x and z are showing the same time while y is one hour behind x. 

We are running CF 9,0,1,274733.  Any idea how to debug this?

Thanks.

    This topic has been closed for replies.

    1 reply

    A
    Adam Cameron.
    Inspiring
    November 5, 2012

    Well firstly your subject line is misleading: this is not a bug with createTimespan().  All createTimespan() does is create a number representing a number of days (or fraction thereof).  It is completely unaware of things like daylight saving because it's got nothing to do with dates and times. You can test this by outputing just the timespan values.  Or you could also demonstrate it by adding zero or 1/24 to now() instead of using createTimespan().

    Instead of using addition - which causes the date value of now to be cast to a numeric and back to a date again for the timeFormat() call - what happens if you use dateAdd() and add zero hours and one hour respectively?

    What time of day was it when you tried this?  Did it matter?

    What TZ are you in?

    What JVM version are you running (this should not be a problem on CF9, but it'll be where any TZ bugs lie if there are any).

    --

    Adam

    A
    Anonymous
    November 5, 2012

    Hi,

    Restarted the server and the bug went away.  Still puzzled as to what caused the issue.  When I output createTimeSpan(0,0,0,0), I got zero.  So I don't know why now() + createTimeSpan(0,0,0,0) gave a time that is one hour behind.  I should have experimented by doing now() + 0, but can't replicate it now.

    Thanks.

    A
    Adam Cameron.
    Inspiring
    November 5, 2012

    It will quite possibly be down to the value of now() at the time you were testing.  For argument's sake when the clocks go back, there will be two occurrences of 1:01am (well: it depends on what time the clocks go back in your TZ): one when the original flow of DLS time initially goes from 1:00am to 1:01am, and then again one minute after the clocks go back from 2am to 1am.  It'll depend when considerations like that come into play when casting dates to numbers and back again.

    As to why now()+0 gave different results to just now(), it'll be because what I alluded to: using a numeric arithmetic operator on a date object (which you really oughtn't do) requires the date to be converted to a number first, and then when you use timeFormat() (which requires a date object for the first argument), it's converted back to a date.  And there's obviously some "idiosyncracy" in there somewhere during that process that treats DLS (or TZs or something) in a way you're not expecting.  I suspect it was not the adding zero that was the problem, it was converting the numeric result back to a date that did it.  And I suspect if you used dateAdd(), there would have been no problem.

    I also suspect if there was an actual bug in CF, we'd be hearing about it from more than one person, so I reckon it's a quirk in your code, not in CF or the JVM.  So... it means the quirk is still there, and will hit you again next year.  You really oughta find it and fix it.

    --

    Adam

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