date literals
Robert Sayre writes:
I think the date literal should allow a trailing 'Z' to substitute for '+00:00'. This form is used quite a bit by authors producing similar profiles, such as W3C-DTF, RFC3339, and XML Schema. Web authors will have to accept the form, so the parse method should support it.
Agree. Amended spec.
It looks like the grammar allows an offset of '-00:00'. That may not be desirable. Here's some background on the edge cases of this family of date format:
www.imc.org/atom-syntax/mail-archive/msg13103.html
"RFC 3339 gives a different semantic to a timezone offset of -00:00 from +00:00 and Z which xsd:dateTime (and to the best of my knowledge ISO 8601) doesn't. Sect 4.3 of RFC 3339 reads:"
If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time.
Will this matter for ECMAScript? Once a date literal is parsed it becomes a UTC time stamp, all information about the timezone it came from is lost.
All the data types in ES3 listed in section 15 have literals version (e.g. {} for Object, [] for Array etc) except for Date. Is there any reason that the Kona 15.9.1.15 "Date Time string format" could not be a literal form for date objects?
YYYY-MM-DDTHH:mm:ss.sssTZ
The 'T' in the middle makes this identifiable as a date literal similar to how the 'e' or 'E' of an exponential number literal works.
It would be beneficial to have a date literal as then a JSON object could have date literal values and still be parsed quickly with eval.
Peter
Peter Michaux wrote:
All the data types in ES3 listed in section 15 have literals version (e.g. {} for Object, [] for Array etc) except for Date. Is there any reason that the Kona 15.9.1.15 "Date Time string format" could not be a literal form for date objects?
YYYY-MM-DDTHH:mm:ss.sssTZ
The 'T' in the middle makes this identifiable as a date literal similar to how the 'e' or 'E' of an exponential number literal works.
When lexing this syntax, the lexer would recognize the tokens
N - N - N : N : N .
where N is a NumericLiteral, before seeing that the next 'sssTZ' is invalid and then having to backtrack 10 tokens. This requires something like an LL(*) parser; it is not LL(k) for any finite k (because each NumericLiteral can be an arbitrary number of characters), or in any similar nicely-behaved grammar category. Please don't add syntax like this.
It would be beneficial to have a date literal as then a JSON object could have date literal values and still be parsed quickly with eval.
I'm not sure that is consistent with the general design philosophy of JSON, which is to have a minimal set of built-in types. Typically a JSON-based protocol would just use a string for this. Extending the set of JSON types at this point would result in breakage of existing JSON parsers. Besides, extending JSON is not within the scope of the ES3.1 standard development.
For ECMAScript itself, there's nothing wrong with 'new Date("...")', IMHO.
On Thu, Nov 20, 2008 at 9:40 AM, David-Sarah Hopwood <david.hopwood at industrial-designers.co.uk> wrote:
Peter Michaux wrote:
All the data types in ES3 listed in section 15 have literals version (e.g. {} for Object, [] for Array etc) except for Date. Is there any reason that the Kona 15.9.1.15 "Date Time string format" could not be a literal form for date objects?
YYYY-MM-DDTHH:mm:ss.sssTZ
The 'T' in the middle makes this identifiable as a date literal similar to how the 'e' or 'E' of an exponential number literal works.
When lexing this syntax, the lexer would recognize the tokens
N - N - N : N : N .
where N is a NumericLiteral, before seeing that the next 'sssTZ' is invalid and then having to backtrack 10 tokens. This requires something like an LL(*) parser; it is not LL(k) for any finite k (because each NumericLiteral can be an arbitrary number of characters), or in any similar nicely-behaved grammar category. Please don't add syntax like this.
I'm a little confused. I don't suppose it makes a difference to what sort of parser is required, but I wouldn't have thought that the parser would recognize something like 12T06 as a numeric literal. Wouldn't the T in the middle tip the parser off a little bit earlier than 10 tokens?
Breton Slivka wrote:
On Thu, Nov 20, 2008 at 9:40 AM, David-Sarah Hopwood <david.hopwood at industrial-designers.co.uk> wrote:
Peter Michaux wrote:
All the data types in ES3 listed in section 15 have literals version (e.g. {} for Object, [] for Array etc) except for Date. Is there any reason that the Kona 15.9.1.15 "Date Time string format" could not be a literal form for date objects?
YYYY-MM-DDTHH:mm:ss.sssTZ
The 'T' in the middle makes this identifiable as a date literal similar to how the 'e' or 'E' of an exponential number literal works. When lexing this syntax, the lexer would recognize the tokens
N - N - N : N : N .
where N is a NumericLiteral, before seeing that the next 'sssTZ' is invalid and then having to backtrack 10 tokens. This requires something like an LL(*) parser; it is not LL(k) for any finite k (because each NumericLiteral can be an arbitrary number of characters), or in any similar nicely-behaved grammar category. Please don't add syntax like this.
I'm a little confused. I don't suppose it makes a difference to what sort of parser is required, but I wouldn't have thought that the parser would recognize something like 12T06 as a numeric literal. Wouldn't the T in the middle tip the parser off a little bit earlier than 10 tokens?
Sorry, I missed the T in the middle. But that only changes the details of the argument, not the substance. It should have been:
When lexing this syntax, the lexer would recognize the tokens
N - N -
where N is a NumericLiteral, before seeing that the next 'DD' is invalid as a NumericLiteral because it is followed immediately by an IdentifierStart character, and then having to backtrack 4 tokens. This requires something like an LL(*) parser; it is not LL(k) for any finite k (because each NumericLiteral can be an arbitrary number of characters), or in any similar nicely-behaved grammar category. Please don't add syntax like this.
Peter Michaux wrote:
All the data types in ES3 listed in section 15 have literals version (e.g. {} for Object, [] for Array etc) except for Date. Is there any reason that the Kona 15.9.1.15 "Date Time string format" could not be a literal form for date objects?
YYYY-MM-DDTHH:mm:ss.sssTZ
The 'T' in the middle makes this identifiable as a date literal similar to how the 'e' or 'E' of an exponential number literal works.
It would be beneficial to have a date literal as then a JSON object could have date literal values and still be parsed quickly with eval.
d = true ? T12:00;
What does this mean?
On Wed, Nov 19, 2008 at 6:37 PM, Dean Edwards <dean at edwards.name> wrote:
Peter Michaux wrote:
All the data types in ES3 listed in section 15 have literals version (e.g. {} for Object, [] for Array etc) except for Date. Is there any reason that the Kona 15.9.1.15 "Date Time string format" could not be a literal form for date objects?
YYYY-MM-DDTHH:mm:ss.sssTZ
The 'T' in the middle makes this identifiable as a date literal similar to how the 'e' or 'E' of an exponential number literal works.
It would be beneficial to have a date literal as then a JSON object could have date literal values and still be parsed quickly with eval.
d = true ? T12:00;
What does this mean?
The same as what it means now. There isn't any date literal business in there at all. A date literal would have to be the whole thing
YYYY-MM-DDTHH:mm:ss.sssTZ
Peter
Michael Haufe wrote:
FWIW, VB.NET uses the following syntax for date literals #8/23/1970 3:45:39AM#
Would that not solve the parsing problem?
It would, since # is not otherwise used. But I don't see the point: what is wrong with using 'new Date("...")'? Date literals would be vanishingly rare compared to other literals; there are very few cases where it is correct to use a hard-coded date in a program. (As for dates in JSON, that was already addressed in my previous reply.)
On Nov 19, 2008, at 9:59 PM, David-Sarah Hopwood wrote:
Michael Haufe wrote:
FWIW, VB.NET uses the following syntax for date literals #8/23/1970 3:45:39AM#
Would that not solve the parsing problem?
It would, since # is not otherwise used. But I don't see the point: what is wrong with using 'new Date("...")'? Date literals would be vanishingly rare compared to other literals; there are very few cases where it is correct to use a hard-coded date in a program.
Exactly. FWIW, this is why date literals were considered a long time
ago for ES4, and rejected.
proposals:date_literal_syntax, doku.php?id=proposals:inactive&s=date+literals
I think the date literal should allow a trailing 'Z' to substitute for '+00:00'. This form is used quite a bit by authors producing similar profiles, such as W3C-DTF, RFC3339, and XML Schema. Web authors will have to accept the form, so the parse method should support it.
It looks like the grammar allows an offset of '-00:00'. That may not be desirable. Here's some background on the edge cases of this family of date format:
www.imc.org/atom-syntax/mail-archive/msg13103.html
"RFC 3339 gives a different semantic to a timezone offset of -00:00 from +00:00 and Z which xsd:dateTime (and to the best of my knowledge ISO 8601) doesn't. Sect 4.3 of RFC 3339 reads:"
I think the date literal should allow a trailing 'Z' to substitute for '+00:00'. This form is used quite a bit by authors producing similar profiles, such as W3C-DTF, RFC3339, and XML Schema. Web authors will have to accept the form, so the parse method should support it. It looks like the grammar allows an offset of '-00:00'. That may not be desirable. Here's some background on the edge cases of this family of date format: <http://www.imc.org/atom-syntax/mail-archive/msg13103.html> "RFC 3339 gives a different semantic to a timezone offset of -00:00 from +00:00 and Z which xsd:dateTime (and to the best of my knowledge ISO 8601) doesn't. Sect 4.3 of RFC 3339 reads:" If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time. -- Robert Sayre