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
On Wed, Jul 17, 2013 at 5:11 PM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Jul 17, 2013, at 16:59 , Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jul 17, 2013 at 7:55 PM, Brandon Benvie bben...@mozilla.com wrote:
On 7/17/2013 4:54 PM, Norbert Lindenberg wrote:
On Jul
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
On Mon, Jul 22, 2013 at 7:07 AM, Mark S. Miller erig...@google.com 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
On Mon, Jul 22, 2013 at 7:42 AM, Allen Wirfs-Brock
al...@wirfs-brock.com 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
On Jul 22, 2013, at 9:42 AM, Jonas Sicking wrote:
On Mon, Jul 22, 2013 at 7:42 AM, Allen Wirfs-Brock
al...@wirfs-brock.com 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
On Mon, Jul 22, 2013 at 10:28 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jul 22, 2013, at 9:42 AM, Jonas Sicking wrote:
On Mon, Jul 22, 2013 at 7:42 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
3. Is it ever appropriate for a DOM API to accept and retain a reference to
a
On Monday, July 22, 2013, Jonas Sicking wrote:
On Mon, Jul 22, 2013 at 10:28 AM, Allen Wirfs-Brock
al...@wirfs-brock.com javascript:; wrote:
On Jul 22, 2013, at 9:42 AM, Jonas Sicking wrote:
On Mon, Jul 22, 2013 at 7:42 AM, Allen Wirfs-Brock
al...@wirfs-brock.com javascript:; wrote:
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
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
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 object
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
I
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 would be a
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 same
On Jul 17, 2013, at 20:35 , Brendan Eich bren...@mozilla.com wrote:
Norbert Lindenberg wrote:
On Jul 17, 2013, at 17:27 , Mark S. Millererig...@google.com wrote:
This is unfortunate. It does answer Anne's question though, in an
unpleasant way: Date instances cannot be immutable; they can
On Thu, Jul 18, 2013 at 12:44 PM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Jul 17, 2013, at 20:35 , Brendan Eich bren...@mozilla.com wrote:
Norbert Lindenberg wrote:
On Jul 17, 2013, at 17:27 , Mark S. Millererig...@google.com wrote:
This is unfortunate. It does
On Wed, Jul 17, 2013 at 11:44 AM, Anne van Kesteren ann...@annevk.nl 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
From: Anne van Kesteren [ann...@annevk.nl]
Is there a better way?
```
video.startDate() !== video.startDate()
```
?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Domenic Denicola wrote:
From: Anne van Kesteren [ann...@annevk.nl]
Is there a better way?
```
video.startDate() !==video.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
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
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
On Wed, Jul 17, 2013 at 3:06 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Jul 17, 2013 at 11:44 AM, Anne van Kesteren ann...@annevk.nl
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
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
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?
```
video.startDate() !==video.startDate()
```
Using a method instead of a getter is better style where the result is
generated on each call,
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
On Wed, Jul 17, 2013 at 1:04 PM, Rick Waldron waldron.r...@gmail.com 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:
Anne van Kesteren wrote:
On Wed, Jul 17, 2013 at 1:04 PM, Rick Waldronwaldron.r...@gmail.com 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).
On Wed, Jul 17, 2013 at 4:40 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Jul 17, 2013 at 1:04 PM, Rick Waldron waldron.r...@gmail.com
wrote:
Can you explain why startDate was specified was a Date object?
Because that's how JavaScript represents time?
Brendan's response is much
On Wed, Jul 17, 2013 at 1:58 PM, Brendan Eich bren...@mozilla.com 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
On Wed, Jul 17, 2013 at 2:50 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Wed, Jul 17, 2013 at 4:40 PM, Anne van Kesteren ann...@annevk.nl 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
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 3:24 PM, Brendan Eich bren...@mozilla.com 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
On Wed, Jul 17, 2013 at 3:37 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Jul 17, 2013 at 3:24 PM, Brendan Eich bren...@mozilla.com 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
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
On Wed, Jul 17, 2013 at 4:36 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jul 17, 2013 at 3:37 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Jul 17, 2013 at 3:24 PM, Brendan Eich bren...@mozilla.com wrote:
Anne van Kesteren wrote:
Right, but we all use a number (and newer specs
On Jul 17, 2013, at 13:58 , Brendan Eich bren...@mozilla.com 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
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
On Jul 17, 2013, at 16:51 , Brandon Benvie bben...@mozilla.com 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
On 7/17/2013 4:54 PM, Norbert Lindenberg wrote:
On Jul 17, 2013, at 16:51 , Brandon Benvie bben...@mozilla.com 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
On Wed, Jul 17, 2013 at 4:42 PM, Brandon Benvie bben...@mozilla.com 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
On Thu, Jul 18, 2013 at 1:55 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jul 17, 2013 at 4:42 PM, Brandon Benvie bben...@mozilla.com
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
On 7/17/2013 4:55 PM, Jonas Sicking wrote:
On Wed, Jul 17, 2013 at 4:42 PM, Brandon Benvie bben...@mozilla.com 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
On Wed, Jul 17, 2013 at 7:55 PM, Brandon Benvie bben...@mozilla.com wrote:
On 7/17/2013 4:54 PM, Norbert Lindenberg wrote:
On Jul 17, 2013, at 16:51 , Brandon Benvie bben...@mozilla.com wrote:
On 7/17/2013 4:42 PM, Brandon Benvie wrote:
On 7/17/2013 4:36 PM, Jonas Sicking wrote:
Is this
On Jul 17, 2013, at 16:59 , Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jul 17, 2013 at 7:55 PM, Brandon Benvie bben...@mozilla.com wrote:
On 7/17/2013 4:54 PM, Norbert Lindenberg wrote:
On Jul 17, 2013, at 16:51 , Brandon Benvie bben...@mozilla.com wrote:
On 7/17/2013 4:42 PM, Brandon
On Jul 17, 2013, at 16:48 , Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jul 17, 2013 at 4:36 PM, Jonas Sicking jo...@sicking.cc 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
On Jul 17, 2013, at 17:27 , Mark S. Miller erig...@google.com 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
Norbert Lindenberg wrote:
On Jul 17, 2013, at 13:58 , Brendan Eichbren...@mozilla.com 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
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
Norbert Lindenberg wrote:
On Jul 17, 2013, at 17:27 , Mark S. Millererig...@google.com 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
50 matches
Mail list logo
