Frozen Date objects?

Rick Waldron waldron.rick at
Wed Jul 17 13:04:23 PDT 2013

On Wed, Jul 17, 2013 at 3:06 PM, Anne van Kesteren <annevk at> wrote:

> On Wed, Jul 17, 2013 at 11:44 AM, Anne van Kesteren <annevk at>
> wrote:
> > Is it intentional that Date objects cannot be frozen?
> >
> > Use case: exposing the time of an event through a Date object while
> > not allowing fiddling with it.
> I was told frozen is only for properties. That doesn't seem ideal.
> Then IDL defines to always return a new Date object, which seems bad:
> % <video>.startDate != <video>.startDate
> true
> Is there a better way?

Can you explain why startDate was specified was a Date object? I've just
read the relevant portions of specification and I don't see any compelling
rationale. I did see the word "timestamp" used in a number of places, but
that contradicts the value type of event.timeStamp, which is |readonly
attribute DOMTimeStamp|—I make this comparison, because I would assume all
things described as "timestamp" would have the same value type. If
startDate were |readonly attribute DOMTimeStamp| (or more appropriately:
{[[Value]]: ..., [[Writable]]: false, [[Enumerable]]: true,
[[Configurable]]: false}), then user code could create a Date object if it
needed to or calculate the difference between some event's timeStamp and
the startDate, etc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list