Duplicate code (Date2) about base2 HOT 23 CLOSED

This is of course no Defect, but an Enhancement.

I prefer my parser as it seems a bit simpler. It is only a small change to make 
it UTC.

Your code is indeed more elegant. But I reckon, because date/time stuff is not 
really regular, code shouldn't 
be either. But hey, it's your library. But before all, it should be correct. 

Another difference in behaviour (very minor):
"T00:00:00:5678" will result in a date.getSeconds()==5 and it should be 0 (5678 
needs to be rounded to 568, 
because it are milliseconds, and not hectomicroseconds).

And I can port my testcases...
Shall I fix those bugs in you code?

Fix my code and upload your test cases to svn/trunk/test/.

hectomicroseconds!? :-P

I'm thinking of creating a separate namespace for the Array2/Date2/String2 etc.

e.g.

base2.JavaScript.bind(window);
base2.JavaScript.bind(Array);

A bit like base2.DOM.bind(); but fixes native JavaScript objects. What do you 
think?

I like it. base2.JavaScript.bind(Array); this will enhance the native Array 
with our Array2 extra's, I assume? What 
does base2.JavaScript.bind(window); actually do? And I take Date2 is still 
usable, if one doesn't want to bind.

And of course:
  base2.JavaScript.bind(window,Array,Date);

base2.JavaScript.bind(window) will upgrade all of the native objects to base2
objects. Static methods would be copied across and the prototypes would be 
augmented.
It is equivalent to base2.DOM.bind(document).

And yes, Array2, Date2, etc would still be usable much like the base2.DOM 
library
methods are still usable. I want base2 to be unobtrusive. But I want to be able 
to
sprinkle the sugar easily. :-)

The candy man can! 

We might have gotten our self a mascotte or logo ;-)

OK. I've removed my Date2, fixed JavaScript/Date2 and created some unit tests. 
Bugfixes:

Date2.toISOString()
- "date = Date(date)" casts to date's string representation, so removed
- suffix "Z" added
- trimmed 0 timeparts
Date2.parse:
- now returns value in ms
- when no match, Date.parse is used
- Milliseconds are now rounded to 3 digits
- Timezones are now supported. Without timezone info, local timezone is 
respected
- Changed internal type from Date2 to Date
- Fixed parsing a time only (break => continue)
- Fixed asserting 

About the tester. I don't think tester.js is the ultimate solution, but I 
didn't want to wait and think longer for some unit tests. If you 
have some better idea's, your welcome to improve it.

Are the fixes OK?

Have you checked in the changes to the Date2 object yet? I just updated and the 
only
changes were in /test/.

Oops. If I'm not careful, this will become a habit ;-)

I noticed JavaScript/Date2.js has not yet been added to package.xml. I've 
worked my way around this in the 
tester.

Date.parse() should return a Date object right? In your changes we now have 

return date.valueOf();

Is that right? date.valueOf() returns a number...

PS/ I'm starting to like the test harness. Much better than my crappy pages.

Date.parse actually returns a number (ms since epoch). I've corrected that:
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Object
s:Date:parse

But we are both right. In the es4 proposal, it returns a Date. I've asked for 
clarification on the es4-list.
Also: current Date.parse returns NaN when the string is not parsible. 

What do we do, when js2 is incompatible with the current js? 
We better wait for the es4-list answer.

Ah, a test harness. Super! Also better than my crappy runner, I hope...

But do you like this kind of tests? 

I'm planning to write some more tests. Any comments on the tests themselves 
would be welcome. 

> What do we do, when js2 is incompatible with the current js?
> We better wait for the es4-list answer.

Mmm. Tricky. JS2 is far away. What's the point in being out of synch with 
real-world
JavaScript. But we'll wait.

> But do you like this kind of tests? 

The tests are great. Please write more. :-)

Brendan Eich himself answered Date.parse returning a Date was a mistake.
He didn't have an answer on the parse-issue, though. So that point stays open.

Almost done. Two questions:
- ISO parse overflow: should return NaN instead of the SyntaxError now thrown? 
What 
do you think: if(console&&console.log) logging?
- I can't think of a sensible way to combine defaultDate and Date.parse (legacy 
parse). Can you?

> ISO parse overflow: should return NaN instead of the SyntaxError now thrown?
Agreed.
> I can't think of a sensible way to combine defaultDate and Date.parse (legacy 
parse). Can you?
No. We should just ignore it for non-ISO dates.

Just checked in a changes to Date2. Date2.parse now returns "new Date(NaN)" 
whenever
the date cannot be parsed.

I thought Date.parse always returns a number... Now it returns a number, except 
if one of the date-parts 
overflow.

My mistake. I'll change it to NaN.