I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=22824 to have
Date object support removed from WebIDL.
Note that this doesn't mean that Date objects can't be returned from
DOM APIs (or any other APIs). It just means that we stop actively
encouraging it. But no APIs are ever forced to limit
And if it ever goes back to the drawing board, make it immutable of course
and please remember that months are numbered from 1 to 12!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Brendan Eich wrote:
Dave has a sad history
LOL! *Date*, not Dave.
Dave has a great history (I know many Daves).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Jonas Sicking wrote:
2) APIs may return Date objects but they should always be newly created
instances and never retain references to them. An API client might mutate such
returned Date objects but that's really the clients business and it will have
no impact upon the DOM.
The emails in th
On Monday, July 22, 2013, Jonas Sicking wrote:
> On Mon, Jul 22, 2013 at 10:28 AM, Allen Wirfs-Brock
> > wrote:
> >
> > On Jul 22, 2013, at 9:42 AM, Jonas Sicking wrote:
> >
> >> On Mon, Jul 22, 2013 at 7:42 AM, Allen Wirfs-Brock
> >> > wrote:
> >>>
> >>>
> >>> 3. Is it ever appropriate for a DOM
On Mon, Jul 22, 2013 at 10:28 AM, Allen Wirfs-Brock
wrote:
>
> On Jul 22, 2013, at 9:42 AM, Jonas Sicking wrote:
>
>> On Mon, Jul 22, 2013 at 7:42 AM, Allen Wirfs-Brock
>> wrote:
>>>
>>>
>>> 3. Is it ever appropriate for a DOM API to accept and retain a reference to
>>> a Date object?
>>
>> We c
Allen's suggesting for accepting Date objects should fall out pretty naturally
as long as the APIs stick to the standard JS style of doing ToNumber on
expected-to-be-number arguments.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozi
On Jul 22, 2013, at 9:42 AM, Jonas Sicking wrote:
> On Mon, Jul 22, 2013 at 7:42 AM, Allen Wirfs-Brock
> wrote:
>>
>>
>> 3. Is it ever appropriate for a DOM API to accept and retain a reference to
>> a Date object?
>
> We could even generalize it to:
>
> 3. Is it ever appropriate for a DOM
On Mon, Jul 22, 2013 at 7:42 AM, Allen Wirfs-Brock
wrote:
>
> On Jul 21, 2013, at 11:05 PM, Jonas Sicking wrote:
>
>
>
> I still don't feel like I have a clear answer to two fundamental
> questions when designing DOM specs:
>
> 1. Is it ever appropriate to return Date objects from methods in the
>
On Mon, Jul 22, 2013 at 7:07 AM, Mark S. Miller wrote:
> For *all* of these, what benefits to Date objects provide over just using
> numbers?
That is indeed the question. I think we attempted to use Date objects
in an effort to be more "javascripty" and less "DOM doing it's own
thing".
But this
On Jul 21, 2013, at 11:05 PM, Jonas Sicking wrote:
>>
>
> I still don't feel like I have a clear answer to two fundamental
> questions when designing DOM specs:
>
> 1. Is it ever appropriate to return Date objects from methods in the
> DOM? If so, in what circumstances. Two cases where we are c
On Wed, Jul 17, 2013 at 5:11 PM, Norbert Lindenberg
wrote:
>
> On Jul 17, 2013, at 16:59 , Jonas Sicking wrote:
>
>> On Wed, Jul 17, 2013 at 7:55 PM, Brandon Benvie wrote:
>>> On 7/17/2013 4:54 PM, Norbert Lindenberg wrote:
On Jul 17, 2013, at 16:51 , Brandon Benvie wrote:
>
Allen Wirfs-Brock wrote:
> Nathan Wall wrote:
>> Last time I asked, `Object.freeze` & friends don't affect existing symbol
>> properties on an object (though new ones can't be added). I think this is
>> pretty important. Has this changed?
>
> Object.freeze and friends affect all properties in the
On Jul 19, 2013, at 7:53 AM, Nathan Wall wrote:
> Domenic Denicola wrote:
>> I believe exposing `[[DateValue]]` as a (non-private) symbol-keyed property
>> would do the trick, since `Object.freeze` seems to set all property keys to
>> non-writable/non-configurable.
>>
>> This seems like it wou
Domenic Denicola wrote:
> I believe exposing `[[DateValue]]` as a (non-private) symbol-keyed property
> would do the trick, since `Object.freeze` seems to set all property keys to
> non-writable/non-configurable.
>
> This seems like it would be a backward-compatible change. But it's so simple
>
Erik Arvidsson wrote:
> This can either be done by exposing an object that has the same
> interface as Date. This could throw on set or it could skip the set
> methods entirely. If you want instanceof to work then all the methods
> needs to be overridden.
Overriding the methods on a real date obje
On Thu, Jul 18, 2013 at 12:44 PM, Norbert Lindenberg <
ecmascr...@lindenbergsoftware.com> wrote:
>
> On Jul 17, 2013, at 20:35 , Brendan Eich wrote:
>
> > Norbert Lindenberg wrote:
> >> On Jul 17, 2013, at 17:27 , Mark S. Miller wrote:
> >>
> >>> This is unfortunate. It does answer Anne's questi
On Jul 17, 2013, at 20:35 , Brendan Eich wrote:
> Norbert Lindenberg wrote:
>> On Jul 17, 2013, at 17:27 , Mark S. Miller wrote:
>>
>>> This is unfortunate. It does answer Anne's question though, in an
>>> unpleasant way: Date instances cannot be immutable; they can be at best
>>> readonly.
On Jul 17, 2013, at 20:29 , Brendan Eich wrote:
> Norbert Lindenberg wrote:
>> On Jul 17, 2013, at 13:58 , Brendan Eich wrote:
>>
>>> No, *time* is stored as milliseconds after the epoch in a number (IEEE
>>> double).
>>>
>>> A Date object includes position on planet and timezone politics (s
Norbert Lindenberg wrote:
On Jul 17, 2013, at 17:27 , Mark S. Miller wrote:
This is unfortunate. It does answer Anne's question though, in an unpleasant
way: Date instances cannot be immutable; they can be at best readonly. Despite
lack of any authorization to track the user's position, Date
Jonas Sicking wrote:
And then there is the thread started at [3], and this particular email
[4] which seems to conclude that Date objects in fact are just
timestamps, and not timezone+timestamp.
[3]https://mail.mozilla.org/pipermail/es-discuss/2013-February/028847.html
[4]https://mail.mozilla.or
Norbert Lindenberg wrote:
On Jul 17, 2013, at 13:58 , Brendan Eich wrote:
No, *time* is stored as milliseconds after the epoch in a number (IEEE double).
A Date object includes position on planet and timezone politics (see
getTimezoneOffset).
No, it doesn't. Any time zone information used
On Jul 17, 2013, at 17:27 , Mark S. Miller wrote:
> This is unfortunate. It does answer Anne's question though, in an unpleasant
> way: Date instances cannot be immutable; they can be at best readonly.
> Despite lack of any authorization to track the user's position, Date
> instances make vis
On Jul 17, 2013, at 16:48 , Jonas Sicking wrote:
> On Wed, Jul 17, 2013 at 4:36 PM, Jonas Sicking wrote:
>>
>> I'm still confused as to when it's correct for an API to return a Date
>> object.
>>
>> At least in SpiderMonkey it's impossible to create Date objects that
>> represent a timezone
On Jul 17, 2013, at 16:59 , Jonas Sicking wrote:
> On Wed, Jul 17, 2013 at 7:55 PM, Brandon Benvie wrote:
>> On 7/17/2013 4:54 PM, Norbert Lindenberg wrote:
>>>
>>> On Jul 17, 2013, at 16:51 , Brandon Benvie wrote:
>>>
On 7/17/2013 4:42 PM, Brandon Benvie wrote:
>
> On 7/17/201
On Wed, Jul 17, 2013 at 7:55 PM, Brandon Benvie wrote:
> On 7/17/2013 4:54 PM, Norbert Lindenberg wrote:
>>
>> On Jul 17, 2013, at 16:51 , Brandon Benvie wrote:
>>
>>> On 7/17/2013 4:42 PM, Brandon Benvie wrote:
On 7/17/2013 4:36 PM, Jonas Sicking wrote:
>
> Is this simply a Spi
On 7/17/2013 4:55 PM, Jonas Sicking wrote:
On Wed, Jul 17, 2013 at 4:42 PM, Brandon Benvie wrote:
On 7/17/2013 4:36 PM, Jonas Sicking wrote:
Is this simply a SpiderMonkey bug? Do we expect JS code to be able to
handle Date objects representing timezones other than the user's
current timezone?
On Thu, Jul 18, 2013 at 1:55 AM, Jonas Sicking wrote:
> On Wed, Jul 17, 2013 at 4:42 PM, Brandon Benvie
> wrote:
> > On 7/17/2013 4:36 PM, Jonas Sicking wrote:
> >>
> >> Is this simply a SpiderMonkey bug? Do we expect JS code to be able to
> >> handle Date objects representing timezones other th
On Wed, Jul 17, 2013 at 4:42 PM, Brandon Benvie wrote:
> On 7/17/2013 4:36 PM, Jonas Sicking wrote:
>>
>> Is this simply a SpiderMonkey bug? Do we expect JS code to be able to
>> handle Date objects representing timezones other than the user's
>> current timezone?
>
>
> What happens if the timezon
On 7/17/2013 4:54 PM, Norbert Lindenberg wrote:
On Jul 17, 2013, at 16:51 , Brandon Benvie wrote:
On 7/17/2013 4:42 PM, Brandon Benvie wrote:
On 7/17/2013 4:36 PM, Jonas Sicking wrote:
Is this simply a SpiderMonkey bug? Do we expect JS code to be able to
handle Date objects representing time
On Jul 17, 2013, at 16:51 , Brandon Benvie wrote:
> On 7/17/2013 4:42 PM, Brandon Benvie wrote:
>> On 7/17/2013 4:36 PM, Jonas Sicking wrote:
>>> Is this simply a SpiderMonkey bug? Do we expect JS code to be able to
>>> handle Date objects representing timezones other than the user's
>>> current
On 7/17/2013 4:42 PM, Brandon Benvie wrote:
On 7/17/2013 4:36 PM, Jonas Sicking wrote:
Is this simply a SpiderMonkey bug? Do we expect JS code to be able to
handle Date objects representing timezones other than the user's
current timezone?
What happens if the timezone changes between the creat
On Jul 17, 2013, at 13:58 , Brendan Eich wrote:
> No, *time* is stored as milliseconds after the epoch in a number (IEEE
> double).
>
> A Date object includes position on planet and timezone politics (see
> getTimezoneOffset).
No, it doesn't. Any time zone information used by getTimeZoneOffs
On Wed, Jul 17, 2013 at 4:36 PM, Jonas Sicking wrote:
> On Wed, Jul 17, 2013 at 3:37 PM, Anne van Kesteren wrote:
>> On Wed, Jul 17, 2013 at 3:24 PM, Brendan Eich wrote:
>>> Anne van Kesteren wrote:
Right, but we all use a number (and newer specs reflect that). Per
your explanation abo
On 7/17/2013 4:36 PM, Jonas Sicking wrote:
Is this simply a SpiderMonkey bug? Do we expect JS code to be able to
handle Date objects representing timezones other than the user's
current timezone?
What happens if the timezone changes between the creation of two Date
objects, such as for dayligh
On Wed, Jul 17, 2013 at 3:37 PM, Anne van Kesteren wrote:
> On Wed, Jul 17, 2013 at 3:24 PM, Brendan Eich wrote:
>> Anne van Kesteren wrote:
>>> Right, but we all use a number (and newer specs reflect that). Per
>>> your explanation above that makes sense and I guess we should continue
>>> to do
On Wed, Jul 17, 2013 at 3:24 PM, Brendan Eich wrote:
> Anne van Kesteren wrote:
>> Right, but we all use a number (and newer specs reflect that). Per
>> your explanation above that makes sense and I guess we should continue
>> to do that then. Not sure if startTime can still be changed.
>
> I hope
Anne van Kesteren wrote:
Right, but we all use a number (and newer specs reflect that). Per
your explanation above that makes sense and I guess we should continue
to do that then. Not sure if startTime can still be changed.
I hope so. At the very least, can you forward my reply to the editors
On Wed, Jul 17, 2013 at 2:50 PM, Rick Waldron wrote:
> On Wed, Jul 17, 2013 at 4:40 PM, Anne van Kesteren wrote:
>> Event.timeStamp was
>> supposed to be a Date object too:
>> http://www.w3.org/TR/DOM-Level-2-Events/ecma-script-binding.html Not
>> sure why it was not implemented that way.
>
> I d
On Wed, Jul 17, 2013 at 1:58 PM, Brendan Eich wrote:
> Anne van Kesteren wrote:
>> Because that's how JavaScript represents time?
>
> No, *time* is stored as milliseconds after the epoch in a number (IEEE
> double).
>
> A Date object includes position on planet and timezone politics (see
> getTime
On Wed, Jul 17, 2013 at 4:40 PM, Anne van Kesteren wrote:
> On Wed, Jul 17, 2013 at 1:04 PM, Rick Waldron
> wrote:
> > Can you explain why startDate was specified was a Date object?
>
> Because that's how JavaScript represents time?
Brendan's response is much nicer then mine.
> Event.timeSta
Anne van Kesteren wrote:
On Wed, Jul 17, 2013 at 1:04 PM, Rick Waldron wrote:
Can you explain why startDate was specified was a Date object?
Because that's how JavaScript represents time?
No, *time* is stored as milliseconds after the epoch in a number (IEEE
double).
A Date object includ
On Wed, Jul 17, 2013 at 1:04 PM, Rick Waldron wrote:
> Can you explain why startDate was specified was a Date object?
Because that's how JavaScript represents time? Event.timeStamp was
supposed to be a Date object too:
http://www.w3.org/TR/DOM-Level-2-Events/ecma-script-binding.html Not
sure why
On 7/17/2013 1:30 PM, Allen Wirfs-Brock wrote:
Didn't we discuss making the [[DateValue]] immutable when a Date object is
non-extensible? I see this isn't currently in the ES6 draft. Also, thinking
about it now, that seems like quite a one-off hack.
It also brings up the question of, for ex
On Jul 17, 2013, at 12:41 PM, Brendan Eich wrote:
> Domenic Denicola wrote:
>> From: Anne van Kesteren [ann...@annevk.nl]
>>> Is there a better way?
>>
>> ```
>> .startDate() !==.startDate()
>> ```
>
> Using a method instead of a getter is better style where the result is
> generated on each c
Exposing [[DateValue]] as a property does not really scale. What about
[[MapData]]? What about private state stored in a closure or a
WeakMap?
This can either be done by exposing an object that has the same
interface as Date. This could throw on set or it could skip the set
methods entirely. If yo
On Wed, Jul 17, 2013 at 3:06 PM, Anne van Kesteren wrote:
> On Wed, Jul 17, 2013 at 11:44 AM, Anne van Kesteren
> 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
From: Domenic Denicola [dome...@domenicdenicola.com]
> This seems like it would be a backward-compatible change.
Well, OK, this is actually just false: code that previously did
`Object.freeze(dateObj); dateObj.setDays(3);` would no longer work as expected.
I guess that might kill this idea?
Or
I believe exposing `[[DateValue]]` as a (non-private) symbol-keyed property
would do the trick, since `Object.freeze` seems to set all property keys to
non-writable/non-configurable.
This seems like it would be a backward-compatible change. But it's so simple I
imagine it's been discussed befor
Domenic Denicola wrote:
From: Anne van Kesteren [ann...@annevk.nl]
Is there a better way?
```
.startDate() !==.startDate()
```
Using a method instead of a getter is better style where the result is
generated on each call, but doesn't get at Anne's question.
IIRC Mark has thoughts about fr
From: Anne van Kesteren [ann...@annevk.nl]
> Is there a better way?
```
.startDate() !== .startDate()
```
?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Wed, Jul 17, 2013 at 11:44 AM, Anne van Kesteren 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
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.
--
http://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozil
53 matches
Mail list logo
