Bug with createTimeSpan

Report · Nov 04, 2012

Hi,

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

x: #timeFormat( x, "h:mm tt" )#

y: #timeFormat( y, "h:mm tt" )#

z: #timeFormat( z, "h:mm tt" )#

</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.

Report · Nov 04, 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

Report · Nov 04, 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.

Report · Nov 05, 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

Report · Nov 05, 2012

minli98 wrote:
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.

You shouldn't be surprised at all. The maths you've been doing is wrong. The answers you get are mostly coincidence. So, you should not expect to get any consistent pattern.

You have been adding 2 dates together, like this

Monday, 5 November 2012 + 1 hour

While this may look all right intuitively, it is ambiguous in most programming languages. Here, you are trying to add an apple to an apple seed. When confronted with such a situation, most languages make an intelligent guess and shrink the apple down to its seeds to enable addition.

Thus, to enable the above addition, ColdFusion might do its best and cast the date into some number of hours. Add to this the complications arising from the fact that a date can be represented in numerous ways. Your method is therefore not one whose results can be reproduced consistently.

The following test will show you that some of the results even fail the basic isDate test:

Is x a date? Answer: #isDate(x)#

Is y a date? Answer: #isDate(y)#

Is z a date? Answer: #isDate(z)#

</cfoutput>

As Adam rightly says, you should use dateAdd("h",1,now()) in place of now() + createTimeSpan( 0, 1, 0, 0).