Bug 32810 – Date binding support for Objective-C

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Kent Tamura]

Like Bug#32698 for JavaScriptCore, we need to support Date type binding for Objective-C DOM binding.

[Kent Tamura]

Created attachment 45365 [details]
Proposed patch

This patch is similar to patches in Bug#32698 and Bug#32699.

[WebKit Review Bot]

style-queue ran check-webkit-style on attachment 45365 [details] without any errors.

[Kent Tamura]

Generated code will be:

- (double)valueAsDate
{
    return IMPL->valueAsDate();
}

- (void)setValueAsDate:(double)newValueAsDate
{
    WebCore::ExceptionCode ec = 0;
    IMPL->setValueAsDate(newValueAsDate, ec);
    WebCore::raiseOnDOMError(ec);
}

[Kent Tamura]

Created attachment 45369 [details]
Proposed patch (rev.2)

- Remove #ifdef !LANGUAGE_COM.  COM binding support was removed.

[WebKit Review Bot]

style-queue ran check-webkit-style on attachment 45369 [details] without any errors.

[Darin Adler]

Comment on attachment 45369 [details]
Proposed patch (rev.2)

The type should be NSAbsoluteTime, not double.

[Timothy Hatcher]

Comment on attachment 45369 [details]
Proposed patch (rev.2)

WOuld making IsPrimitiveType return true for Date give you more of the code paths you need with out $idlType eq "Date"? Or is IsPrimitiveType used other places we don't want for Date? Could those be specialcased for Date?

Seems fine though…

[Timothy Hatcher]

Comment on attachment 45369 [details]
Proposed patch (rev.2)

Darin is right, this should be NSAbsoluteTime.

[Darin Adler]

I do think this can be done without adding "Date" in so many different places. Maybe we can claim it's a primitive type.

[Kent Tamura]

(In reply to comment #6)
> The type should be NSAbsoluteTime, not double.

Would you give me information about NSAbsoluteTime please?
I couldn't find it in header files and references.

[Darin Adler]

(In reply to comment #10)
> Would you give me information about NSAbsoluteTime please?
> I couldn't find it in header files and references.

Oops, sorry. It's NSTimeInterval (from NSDate.h). There should be an NSAbsoluteTime, but there is not!

[Darin Adler]

(In reply to comment #11)
> Oops, sorry. It's NSTimeInterval (from NSDate.h). There should be an
> NSAbsoluteTime, but there is not!

But also, dates inside WebKit are in seconds from a base of 1970, whereas in AppKit they have a base of 2001. So we will need to correct by kCFAbsoluteTimeIntervalSince1970 as we do in CurrentTime.cpp.

[Timothy Hatcher]

(In reply to comment #11)
> (In reply to comment #10)
> > Would you give me information about NSAbsoluteTime please?
> > I couldn't find it in header files and references.
> 
> Oops, sorry. It's NSTimeInterval (from NSDate.h). There should be an
> NSAbsoluteTime, but there is not!

There is CFAbsoluteTime, documented with an epoch of 2001. But I think NSTimeInterval is better to use since we are not a CF API.

[Kent Tamura]

Created attachment 45464 [details]
Proposed patch (rev.3)

- Map Date to NSTimeInterval
- Introduce functions to convert double from/to NSTimeInterval.
- Make Date a primitive type

[WebKit Review Bot]

style-queue ran check-webkit-style on attachment 45464 [details] without any errors.

[Eric Seidel (no email)]

Comment on attachment 45464 [details]
Proposed patch (rev.3)

Looks good to me.

[Kent Tamura]

Committed r53890: <http://trac.webkit.org/changeset/53890>