Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at RIA Unleashed (Nov. 2010) with:

Date Addition Using CreateTimeSpan() Creates A Numeric Date

By Ben Nadel on
Tags: ColdFusion

This really isn't news; I am just writing this down to try and drill it into my head. I just spend 10 minutes debugging some old Caching code that uses a CacheUntil date/time stamp. When setting the CacheUntil value, I was using the CreateTimeSpan() to create a future date:

(Now() + CreateTimeSpan( 0, 0, 5, 0 ))

The cache never seemed to be expiring. As part of the logic, the caching controller was checking to see if the CacheUntil value was a date since non-date values would denote a non-expiring data store. It was using ColdFusion's IsDate() function to check the CacheUntil value; IsDate() is great, but it ignores numeric date/time representations. As such, the date I created using the CreateTimeSpan() math was being ignored:

  • <!--- Get a date that is 10 minutes in the future. --->
  • <cfset objFuture = (Now() + CreateTimeSpan( 0, 0, 10, 0 )) />
  • IsDate() :: #IsDate( objFuture )#<br />
  • IsNumericDate() :: #IsNumericDate( objFuture )#<br />

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

IsDate() :: NO
IsNumericDate() :: YES

As you can see, the date math produced a value that IsDate() did not recognize but IsNumericDate() did. I ran into this issue almost three years ago, but I still forget to use IsNumericDate() as my default date/time filter. Remember, remember, remember - just start using IsNumericDate()!

Looking For A New Job?

100% of job board revenue is donated to Kiva. Loans that change livesFind out more »

Reader Comments

Why not just use dateadd('n',5'now())? to adjust your date. Then you don't have to worry about numeric dates?

Reply to this Comment


For some reason, I am simply not a huge fan of DateAdd(). It feels unnatural. Plus, if you are dealing with encapsulated logic or packaged products, I think its a good idea to make it as flexible as possible; if you require your calling code to provide standard date/time stamps only, it cuts out a lot of the logic that people will use to create date/time stamps.

Reply to this Comment

I often use the IsDate() for my date validation but your point seems very valuable here and using IsNumericDate() over IsDate() will solve many problems like this I think.

Reply to this Comment

@Ben, I guess using createtimespan makes more sense if you want to add something like 1 hour and 5 minutes.

Reply to this Comment


Yeah, I really like the way it easily breaks out all the time fields. Very easy to work with.

Reply to this Comment

I've always wondered why some date/times didn't show up as Yes using isDate. This will come in quite handy for me.

Reply to this Comment

your comments to Anthony are insightful; I also would probably have just used dateAdd if I had come across the problem. But I'm not as experienced as you are. I think this is something programmers come across quite often...finding things that aren't new, but that they need to drill into their heads on a regular basis, because for whatever reason, they forget those certain things. Good post. It'll certainly help me remember and drill it into m head. Thanks!

Reply to this Comment


Don't get me wrong - there's nothing wrong with DateAdd() at all. It's just that when you use it, you put more responsibility on the calling code to know the limitations of the implementation. Most of the time, its not an issue; but, anytime you are building something that involves non-standard times, it's probably a good idea to use IsNumericDate().

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.