In <000801bfa4d3$72169300$[EMAIL PROTECTED]>, Seth Petry-
Johnson ([EMAIL PROTECTED]) in a fit of unbridled passion, wrote:
> >CF variables are supposed to be typeless, but then there is the
> >ParseDateTime() function in Cold Fusion which returns a date object from
> >a string.
> >
> >Are there instances where certain functions require a bonafide date
> >"object"?
>
>
> The CF date/time functions such as DateAdd(), DateCompare(), etc all seem to
> accept either date/time objects -or- string representations of dates as
> their arguments. Supplying these functions with string representations of
> dates doesn't seem to cause any problems (at least in my limited testing on
> CF 4.01) provided of course that the strings represent valid dates.
>
> I would guess then that the ParseDateTime() function exists for performance
> reasons. I can only assume that the date functions perform faster when
> supplied with actual date/time objects because they don't have to do any
> internal conversions from string objects. This doesn't seem to be
> noticeable under normal circumstances but it might help if you had to run
> some hefty loops that performed date/time calculations.
>
> Note that this entire theory is just that, a theory. I could be talking
> complete nonsense here... <g>
I didn't even *notice* the ParseDateTime() function till about a few
months ago. For years, I've just been sending plain text strings into
all the date functions in CF that I've ever needed to use..
I bet you're right, though -- performance reasons. Now if there were
only a way when retrieving a date column from Oracle for it to
automatically be read by CF as a CF "date object". Anyone know?
TIA,
-R
------------------------------------------------------------------------------
Archives: http://www.eGroups.com/list/cf-talk
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
