added deserialization of Date attributes for custom elements

[bsatrom]

Here's my first pass at adding Date deserialization support to attrs.js, as per #119 (tests included). Let me know what you think, and/or if I need to make any additional changes.

[sjmiles]

Thanks for working on this.

I think we want to avoid doing any parsing outside of Date.parse.

If we really want to add a new type of string date format, I suggest we do it by overriding Date.parse and not inline in attrs.js.

WDYT?

[bsatrom]

Do you mean to say that attrs.js should only support YYYY/MM/DD formats (as opposed to also . and -)? If so, that's okay by me. That additional logic was in there to paper over inconsistencies w/ how the Date constructor handles the latter two types of strings, anyway.

As for Date.parse, do you think we even need to do that, or will new Date(inValue) do? new Date() passes all of the specified tests, and adding Date.parse doesn't seem to add any value, unless of course i'm not testing a case where it would be needed.

If just using new Date() is fine, I'll update the PR.

[sjmiles]

If we write the Date construction roughly this way:

new Date(Date.parse(value) || Date.now())

Then attrs.js supports whatever formats Date.parse supports.

In a separate module we can opt-in to adding new formats to parse without having to ever bother attrs.js. Something like:

var originalDateParse = Date.parse;
Date.parse = function(s) {
  if (/* s is special*/) {
  // do special handling on s
  else {
    return originalDateParse(s);
  }
}

That way we can decouple Date enhancements from attribute parsing in Toolkit.

[bsatrom]

Thanks Scott, makes sense. I'll update the PR for the baseline case and then whip up a quick module impl for additional format support.

[sjmiles]

Great, thanks again Brandon.

[bsatrom]

Sure thing! Thank you for letting me jump in 👍

[sjmiles]

LGTM