The Daily WTF: Curious Perversions in Information Technology

2006-04-19 Reply Admin

Three pages of comments and no-one's mentioned Date.parse yet? WTF?!

Javascript's Date object has a static parse() method that returns an integer value representing the number of milliseconds between midnight, January 1, 1970 and the date supplied in string. If the string isn't a recognised date, it returns NaN.

function isDate(string) { return(! isNaN(Date.parse(string))); }

I've found it rather handy for doing client-side date validation. :)

2006-04-19 Reply Admin

Digitalbath:

...
Can you pass multiple moose into this function? Mabye a linked list of meese that need validation sorted in decreasely antler size?

A need to pass multiple moose implies a bad case of constipation. Pass in a laxative object and your moose should be returned embedded in a stream.

stealthsid · 2006-04-19 Reply Admin

Code reuse, bandwith is cheap, and "this is a good HACK for a 1.0 version" are not reasons to unnecessarily cross the network boundary!

Sure, the bandwidth and "good enough" rationale works fine for "Billy-Bob and the web site that he done builted to play with AJAX". But if you're working on something that thousands of people use, which sucks down 500 kbps/sec on average (during business hours), crossing the network boundary for something so easy to determine client-side is just foolish... eff oh oh LISH!

Finally what is all with this concern for code reuse? Are they going to change date validation anytime soon? Is it sooo hard to have server-side and client-side date validation code which will never change?

Ok those questions were rhetorical, but riddle me this, what benefit other than the savings in up-front development time (which I'd stipulate is pretty short) do you get from this particular instance of "code reuse"?

2006-04-25 Reply Admin

Decent date validation (such as that I expect is included in .NET) is very difficult to do well, especially when considering different formats/timezones/languages etc. I think this is much better than writing your own half-assed approach that will be ridden with bugs. Most programming libraries make a decent approach, but its exactly the sort of thing that web services are for.

Yes its a bit brutal atm, but it will only get better with time, as network speeds increase etc. Eventually entire operating systems and the like will be available as web services or equivalent (just ask Microsoft and Google what they're upto).

ammoQ · 2006-04-25 Reply Admin

Anonymous:
Decent date validation (such as that I expect is included in .NET) is *very* difficult to do well, especially when considering different formats/timezones/languages etc. I think this is much better than writing your own half-assed approach that will be ridden with bugs. Most programming libraries make a decent approach, but its exactly the sort of thing that web services are for.

Yes its a bit brutal atm, but it will only get better with time, as network speeds increase etc. Eventually entire *operating systems* and the like will be available as web services or equivalent (just ask Microsoft and Google what they're upto).

On the other hand, if format, timezone, language etc. are fixed (e.g. in an intranet project for a regional company), it can be easier to roll your own routines (hardcoded for that format, timezone, language etc.) than to make the standard mechanisms work as needed.

2006-11-02 Reply Admin

Anonymous:

function howMuchWoodCouldAWoodchuckChuck(bool AWoodchuckCouldChuckWood)
{
   if (AWoodchuckCouldChuckWood)
   {
      return true;
   }
   else
   {
      return false;
   }
}

The Long Road to Validation

Leave a comment on “The Long Road to Validation”