Re: [IndexedDB/WebIDL] Dates + Sorting (WAS: Detailed comments for the current draft)

I'd like to see the resolution for this, too.

If what is held inside the browser for a Date object is just a double
or a long long value of the JS [[PrimitiveValue]] internal property
for Date, I guess providing programming language specific bindings for
Date would be easy (java.util.Date in Java, DateTime in C#, etc).

It looks DOMTimeStamp [1] is also indicating this behaviour (long in
Java, Date in JS, though). Is Date the same thing as DOMTimeStamp? Is
it just trying to remove the sentence "For Java, DOMTimeStamp is bound
to the long type. For ECMAScript, DOMTimeStamp is bound to the Date
type because the range of the integer type is too small." from the DOM
Core spec?

[1] http://www.w3.org/TR/DOM-Level-3-Core/core.html#Core-DOMTimeStamp

Best,

 - Shiki

On Fri, Apr 23, 2010 at 5:08 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Tue, Feb 2, 2010 at 8:37 PM, Pablo Castro <Pablo.Castro@microsoft.com>
> wrote:
>>
>> On Mon, Feb 1, 2010 at 1:30 AM, Jeremy Orlow <jorlow@google.com> wrote:
>>
>> > > > 1. Keys and sorting
>>
>> > > > a.       3.1.1:  it would seem that having also date/time values as
>> > > > keys would be important and it's a common sorting criteria (e.g. as part of
>> > > > a composite primary key or in general as an index key).
>>
>> > > The Web IDL spec does not support a Date/Time data type. Could your
>> > > use case be supported by storing the underlying time with millisecond
>> > > precision using an IDL long long type? I am willing to change the spec so
>> > > that it allows long long instead of long IDL type, which will provide
>> > > adequate support for Date and time sorting.
>>
>> > Can the spec not be augmented?  It seems like other specs like WebGL
>> > have created their own types.  If not, I suppose your suggested change would
>> > suffice as well.  This does seem like an important use case.
>>
>> I agree, either we could augment the spec or we could describe it in terms
>> of Javascript object values. That is, we can say something specific about
>> the treatment of Javascript's Date object. Would that be possible? E.g. we
>> could require implementations to provide full order for dates if they find
>> an instance of that type in a path.
>
> I took a look at the WebIDL spec and found the following text:
> """
> Editorial note
>
> HTML 5 uses Date, so we'll need to decide what to do with that.
>
> Current thoughts are to be able to state that an interface has a custom
> mapping to language bindings, and to map that type to a Date in ECMAScript
> and a java.util.Date in Java.
>
> """
> Does this comment imply that there are differences in how the two languages
> treat dates?  Or is the concern that other languages that WebIDL might apply
> to might have different semantics?
> The HTML5 spec seems to specify the parsing of dates in great detail, but
> I'm not sure whether it completely covers everything.  For example, are
> there nuances to sort order that we need to be concerned with?  Since the
> HTML5 spec only allows gregorian calendar dates, comparing based on the
> number of seconds since epoch seems like it'd be enough.  But I'm really not
> an expert on this stuff...
> Does anyone have advice on how would be best for the IndexedDB spec to
> include indexing/ordering based on dates?
> J

Received on Monday, 26 April 2010 09:13:18 UTC