Duplicate code (Date2)

[GoogleCodeExporter]

src/base2/JavaScript/Date2.js and src/utils/Xstra/Date2.js serve the same 
purpose.

Shall we merge code? We might first want to discuss the difference in 
implementations.

- I like your _createObject2
- I like my implementations of toISO and parse better ;-)
- toISO is supposed to serialize in UTC, according to the lastest mailinglist 
entry:
https://mail.mozilla.org/private/es4-discuss/2007-July/000896.html
- the correct name seams "toISOString"
- new Date2(2007,7-1,21).toISOString() should return "2007-7-21T" and not 
"2007-7-
21T00:00:00.0" (return the shortest possible string)
- Date2.parse should use Date.parse if there's no ISO match
- I have test-cases :-P

Original issue reported on code.google.com by doek...@gmail.com on 21 Jul 2007 at 4:09

[GoogleCodeExporter]

This is of course no Defect, but an Enhancement.

Original comment by doek...@gmail.com on 21 Jul 2007 at 4:12

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

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

Original comment by dean.edw...@gmail.com on 23 Jul 2007 at 9:01

[GoogleCodeExporter]

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?

Original comment by doek...@gmail.com on 23 Jul 2007 at 9:20

[GoogleCodeExporter]

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?

Original comment by dean.edw...@gmail.com on 23 Jul 2007 at 9:49

[GoogleCodeExporter]

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);

Original comment by doek...@gmail.com on 23 Jul 2007 at 10:03

[GoogleCodeExporter]

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. :-)

Original comment by dean.edw...@gmail.com on 23 Jul 2007 at 12:34

[GoogleCodeExporter]

The candy man can! 

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

Original comment by doek...@gmail.com on 23 Jul 2007 at 3:48

[GoogleCodeExporter]

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?

Original comment by doek...@gmail.com on 23 Jul 2007 at 3:52

• Changed state: Started

[GoogleCodeExporter]

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

Original comment by dean.edw...@gmail.com on 23 Jul 2007 at 4:17

[GoogleCodeExporter]

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

Original comment by doek...@gmail.com on 23 Jul 2007 at 4:24

[GoogleCodeExporter]

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

Original comment by doek...@gmail.com on 23 Jul 2007 at 4:27

[GoogleCodeExporter]

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.

Original comment by dean.edw...@gmail.com on 23 Jul 2007 at 4:53

[GoogleCodeExporter]

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.

Original comment by doek...@gmail.com on 23 Jul 2007 at 5:25

[GoogleCodeExporter]

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

Original comment by doek...@gmail.com on 23 Jul 2007 at 5:26

[GoogleCodeExporter]

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. 

Original comment by doek...@gmail.com on 23 Jul 2007 at 5:28

[GoogleCodeExporter]

> 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. :-)

Original comment by dean.edw...@gmail.com on 23 Jul 2007 at 5:43

[GoogleCodeExporter]

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.

Original comment by doek...@gmail.com on 23 Jul 2007 at 8:52

[GoogleCodeExporter]

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?

Original comment by doek...@gmail.com on 31 Jul 2007 at 2:28

[GoogleCodeExporter]

> 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.

Original comment by dean.edw...@gmail.com on 10 Aug 2007 at 4:16

[GoogleCodeExporter]

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

Original comment by dean.edw...@gmail.com on 10 Aug 2007 at 9:55

• Changed state: Fixed

[GoogleCodeExporter]

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

Original comment by doek...@gmail.com on 11 Aug 2007 at 12:33

[GoogleCodeExporter]

My mistake. I'll change it to NaN.

Original comment by dean.edw...@gmail.com on 11 Aug 2007 at 7:21

• Changed state: Re-open

[GoogleCodeExporter]

Original comment by dean.edw...@gmail.com on 5 Dec 2007 at 4:48

• Changed state: Fixed