Monday, 10 September 2012

Survey Results: CF strings being interpreted as dates and integers

No articles for a few days, sorry (if indeed I can be so self-indulgent as to think anyone actually gives a toss one way or the other ;-)... I had a busy weekend flitting from London to the other side of Ireland and back in the space of about 40 hours, and have been pretty much shattered as a result.  But here we go now.
I've been running some surveys for a while (see the list of them in the right sidebar), and I've finally got enough results to give some analysis. I decided there was no point in reporting back on a survey unless I got at least 50 results. On a couple of them I'm now well over that, so I'll share the results and editorialise a bit.

The first survey came about because of what I saw as a rather strange comment from Adobe in dealing with a bug (3134331). I say "strange" because they cited "backward compat" as one of the grounds not to not fix it, and then offered a pretty specious explanation of that excuse. I discuss it more thoroughly here.  This is an extension of an outright dismissal of another bug which is related (3169196), which they've outright refused to fix, despite it clearly being a bug.  Again citing backwards compat issues.

I'm using this analysis as an excuse to mess around with Zingcharts (which are cool!)... Not the ColdFusion wrapper for them via <cfchart>, which is completely unnecessary, but just using the native Zingcharts API (which was dead easy). Anyway, standby for death-by-chart.

I'll post the code I used for these in a separate article... I'm not entirely happy with the code I'm using currently, so I might tweak it before admitting to it. It's all JS, so you can look at it right now in the source code of this post if you like, anyhow.

Here are the results.

Q1: What type of data does "6,0" represent to you (choose best answer)?

There's a fair mix here, and even one person saying it's an integer, but they added a comment that they were French, so they were thinking from the perspective that european-formatted numbers us a comma as a decimal separator.  This is true, but unless I am mistaken, whilst CFML supports formatting numbers for output in European format, it doesn't support that formatting natively in its code.  So given the question was what type of data does "6,0" represent, it's pushing the envelope of validity to make the assertion that it could be a European-formatted number. 91% of people picked string or list, which is the best answer to me.  One person said is was a date.  I'm guessing that was someone from the CF team (kidding: it was someone from Aussie)

Q2: In your mind, is this a true statement: "0,6" == "6,0"?

I am gobsmacked that five people said yes to this, and I really wish I'd added a comments box to that question to so they could explain why.  I do not see a situation in which those two strings (or even interpreting them as lists or even numbers or dates!) are equal to each other.  Which is in agreement with the overwhelming majority of people replying.

Q3: Is "d,y" or "y,d" a format you ever use to represent a date?

Three people recognise this as a date format.  If it was you, please post a comment saying in which locale that's a way to format a date, and please give an example of it being used anywhere else other than in the internals of ColdFusion.  If it's legit, I will reverse my position here.

Q4: Your previous answer notwithstanding, if we choose to consider "d,m" to be a legitimate date format, is the notion of the "zeroth of the month" (wherein that is the last day of the previous month) a legitimate way to interpret "0,6" (ie: as May 31)?

Three people said yes to this one.  Again, if one was you, please provide an example of this in practice.  I don't mean some contortion of computer-based date arithmetic (JavaScript, for example, will treat the zeroth of the month as the last day of the previous month), but a real-world example.

Q5: Is it a bug in ColdFusion that isValid("date", "0,6") returns TRUE?

Five people this time.  So two people who didn't think that 0,6 was a legitimate way of representing a date still think it should be considered a valid date by CF.  Huh?

Q6: Is it a bug in ColdFusion that isValid("integer", "0,6") returns TRUE?

I'm not going to pick on the outliers here... the bulk of people agree that this ain't an integer.  I cannot see how anyone could legitimately think otherwise (OK, I lied.  I'm picking on the outliers).  But, please, do tell.  Note the question is whether it's a valid integer, so "European format" doesn't help you here because that'd be 0.6 in the English-speaking world.  Not an integer.

Q7: Do you think you have any code that actively or coincidentally relies on this behaviour?

I'm actually speechless at this (that the answer is not 100% "no").  Maybe I'm missing something.

Q8: Which statement best reflects your thoughts?

This is the important question.  86% of people just say "fix it".  Another 11% are much the same mind.  That's 97%.  One person reckons it's not a bug, and another reckons it is, but best not fix it. I should have had a comments box on this one too, I think.

Q9: Please best indicate your reaction to how Adobe is dealing with the issue described in bug 3169196?

Well indeed.  'Nuff said. Personally I put "disappointed" here, but I am really ambivalent about that specific bug, but disappointed in the general attitude displayed by them on this.  Oh, and I voted with the majority on all the other questions.  I tried not to make the questions leading, but I dunno if I achieved that.  It's the first survey I've ever put together, and I learned a bit from that.  Sometimes the comments (which I did not allow enough opportunity for here) are more telling than the survey answers.  I have given more scope for comments in my subsequent surveys.

I think the bottom line here demonstrated that Adobe's position that this sort of thing is a risk to fix due to backwards compat concerns is a bit facile. I get that there is a theoretical possibility that someone could be using this code in such a way that they require the buggy behaviour for their code to work, but let's think about this:
  • the same could be said of any bug.  If for example pi() returned 3 instead of 3.14[etc], I could leverage that to my own ends... this does not mean pi() shold not be fixed to return the correct value, it just means I've been daft, and I've got some rework heading my way);
  • one needs to use common-sense and dwell in the real world when making these decisions as to whether backwards compat is a consideration. The chance that anyone is leveraging this bug is going to be do shrinkingly small as to not be worth worrying about;
  • the fact that code was ever written this way is a bit embarrassing for Adobe: 0,6 is simply not something that should be interpreted as a date or by extension an integer, in even the most liberally-loosely-typed system.  It is neither a date nor an integer.  End of story.  So to report that it is is wrong;
  • if people did accidentally have this in their code, I imagine they'd not only be happy to fix it, they'd be happy to have it pointed out that they've got some dodgy code going on.  But let's face it: I'm talking about a fictitious situation because plain and simple no-one will be doing this.
I think I have two recommendations here.  Firstly, Adobe should fix that bug.  Mostly on principle.  I know they have said it's deferred, so perhaps it is in the pipeline. Secondly - and far more importantly - they need to be a bit more realistic before they consign something to the dust heap due to some contrived, contorted explanation that it's a backwards compat issue.

That's enough of blimin' computers for the day.  I'm off to watch telly.