Why is there an offset when using DateConvert with DateCompare?

Question

I'm developing on my local server and my current timezone is GMT +11 hours.
<cfset date1 = DateConvert("Local2UTC", now())>
<cfset date2 = '2014-03-06'> <!--- (Tomorrow at time of writing) --->
So, I was expecting that when I ran this code:
#DateCompare(date1,date2,'d' )#
that it would return a "-1" but it returned a "0" implying that the "day" was the same.
So, to double check I output:
DateConvert("Local2UTC", now())
grabbed its displayed value : {ts '2014-03-05 07:08:58'} and inserted that for comparison thus:
DateCompare("{ts '2014-03-05 07:08:58'}",date2,'d' ) and sure enough, it did return a "-1" reflecting that the day of date1 is indeed earlier than date 2.
Further investigation showed that  I had to add my timezone difference to date2 in hours thus:
<cfset date2 = '2014-03-06 11:00:00> to get
#DateCompare(date1,date2,'d' )#
to return a "-1".
Is this a bug or am I misinterpreting??

Answer 1

Hmmm, like with like and all other good practices aside, there is a bug. Also, like just about everyone else, I develop locally in one timezone +10 hours and run my sites remotely on a different timezone -5 hours, altogether a significant time difference. So after coming to understand how to deal with the bug I've come up with a way to compare dateTimes on the remote server, but it does require a spot of copying a string in where you've been advising not to.
First, to the dateCompare() bug. To expose the bug we better use a finer increment than days, so instead of specifying, simply leave the “datepart” attribute empty so that it defaults to seconds. You say you’re in a +1hour timezone so try this.
Presuming a local time of 16:00 on August 7th 2014
<cfset date1 = DateConvert('local2Utc', now())>
<cfdump var="#date1#"> should produce {ts '2014-08-07 15:00:00'}
Now create a dateTime using CreateDateTime(2014,08,07,15,30,00) This time half way between your local dateTime and UTCDateTIme.
<cfset date2 = CreateDateTime(2014,08,07,15,30,00)>
Now compare them <cfdump var="# DateCompare(date1, date2 )#> in this example on your local server, you would expect to return a -1 since date1 is earlier, but in fact it will return a +1 because it seems to be somehow only looking at the now() time (later) instead of the UTC converted time. This is a bug, DateCompare should not care where it gets its data from it should simply get it and then compare the two values. Usually there is no problem using dateCompare but when used in conjunction with the DateConvert('local2Utc', now()) it ignores the value generated by the conversion. Anyway, so much for the bug, Now to the procedure that I’m using that requires copying a string.
I’m wishing to compare a dateTime that I want something to stop being displayed on the remote server.
<cfset myDate = CreateDateTime(2014,08,05,17,0,0)>
<cfset myDateInUTC = DateAdd("s", GetTimeZoneInfo().UTCTotalOffset, myDate)>
<cfdump var="#myDateInUTC#">
This produces the string: {ts '2014-08-15 07:00:00'} .
I then generate currentUTCDateTime from:
<cfset currentUTCDateTime = DateAdd("s", GetTimeZoneInfo().UTCTotalOffset, now())>
Both these dates are then compared thus:
DateCompare(currentUTCDateTime, "{ts '2014-08-07 15:00:00'}" )
I have to generate the string on my local server and then upload it which is why I’m unable to simply use a function. It’s a bit convoluted but it does work. Note that in this example I’m setting the currentUTCDateTime using DateAdd instead which doesn’t trip up like DateConvert.