ColdFusion CreateTimeSpan() And CFLoop (via Ray Camden)

I was just reading over on Ray Camden's blog about a user-submitted issue with the CFLoop behavior using times and a CreateTimeSpan()-based increment. Here is code equivalent to what Ray's reader submitted:

Notice that we are looping from 9AM to 10AM and are using a Step value of 5 minutes as determined by ColdFusion's CreateTimeSpan() method. When we run the above code (and this was the same on Ray's blog), we get the following output:

09:00
09:05
09:10
09:15
09:20
09:25
09:30
09:35
09:40
09:45
09:50
09:55
10:00

10:00
10:05
10:10
10:15
10:20
10:25
10:30
10:35
10:40
10:45
10:50
10:55

Notice that the first loop runs 13 times, ending on the following hour, while the second loop runs only 12 times and ends on the 55 of the current hour.

So what's going on here? As Ray pointed out in his post, the value of the loop index becomes a floating point number - a number representation of the date. But, when I look at the above loop, you know what really sticks out at me in a huge way? The use of time values like "9 AM" and "10 AM". Something about this just seems really funky. I can't tell you why - it's just a gut feeling.

Acting on the gut feeling, I decided to make my From and To attributes a bit more explicit as far as time. Since we don't really care about the date, just the time, I'm going to define the From and To attributes in the same way that I'm defining my CFLoop step value - using CreateTimeSpan():

This time, we aren't letting ColdFusion interpret "9AM" or "10AM" as a valid date/time stamp - we are telling it explicitly how to handle our numeric date representations. And, when we run this code, we get the following output:

09:00
09:05
09:10
09:15
09:20
09:25
09:30
09:35
09:40
09:45
09:50
09:55
10:00

10:00
10:05
10:10
10:15
10:20
10:25
10:30
10:35
10:40
10:45
10:50
10:55
11:00

Sweeet! This time, both CFLoops iterate 13 times and end on the following hour. This is the kind of behavior we want to see.

Having done this, I then got curious as to whether it was a numeric date representation issue, or if it was a string-to-date/time conversion issue. To test this, I ran another experiment, this time defining the From and To attributes using CreateTime(). CreateTime(), just like CreateDate(), does not create a numeric date, but rather a standard ColdFusion date/time stamp based off of the ColdFusion "zero date":

CreateTime( 9, 0, 0 ) == {ts '1899-12-30 09:00:00'}

As you can see, CreateTime() creates a valid date/time stamp (just like Now() or ParseDateTime()). I put this into the CFLoop attributes:

When we run this code, we get the following output:

09:00
09:05
09:10
09:15
09:20
09:25
09:30
09:35
09:40
09:45
09:50
09:55
10:00

10:00
10:05
10:10
10:15
10:20
10:25
10:30
10:35
10:40
10:45
10:50
10:55

Interesting! This methodology fails in the same was as our first methodology (using values like "9AM").

So, what does this mean? We can conclude that the issue is not in how ColdFusion converts a date/time string into a date/time stamp; rather, the issue is in how ColdFusion converts a date/time stamp into a numeric date representation. To get around this, we have two choices: either, we modify the CFLoop to use DateAdd() as Ray pointed out in his blog post; or, if we want to use CreateTimeSpan() for our increment, we must make sure to define all of our limits using CreateTimeSpan().

What Other People Are Searching For

[ local search ] cfloop issues with createtimespan()
[ local search ] using createtimespan with cfloop

You Might Also Be Interested In: