FAQ Proposed Change: Dates

[Garrett Smith]

In the main entry, proposal to add:
| Year 0000 is unrecognized by some formats (XML Schema, xs:date).

And below,

| 4.1 How do I format a Date object with javascript?
|
| A local Date object where year >= 0 can be formatted to a common ISO
| 8601 format YYYY-MM-DD with:-
|
| /** Formats a Date to YYYY-MM-DD (local time), compatible with both
| * ISO 8601 and ISO/IEC 9075-2:2003 (E) (SQL 'date' type).
| * @param {Date} dateInRange year 0000 to 9999.
| * @throws {RangeError} if the year is not in range
| */
| function formatDate(dateInRange) {
| var year = dateInRange.getFullYear(),
| isInRange = year >= 0 && year <= 9999, yyyy, mm, dd;
| if(!isInRange) {
| throw RangeError("formatDate: year must be 0000-9999");
| }
| yyyy = ("000" + year).slice(-4);
| mm = ("0" + (dateInRange.getMonth() + 1)).slice(-2);
| dd = ("0" + (dateInRange.getDate())).slice(-2);
| return yyyy + "-" + mm + "-" + dd;
| }
|
|
| * http://www.merlyn.demon.co.uk/js-date9.htm

 

[Thomas 'PointedEars' Lahn]

In the main entry, proposal to add:
| Year 0000 is unrecognized by some formats (XML Schema, xs:date).

"Some" implies more than one.

a) Change the wording.
b) Remove the example.
c) Add at least one more example.

And below,

| 4.1 How do I format a Date object with javascript?
|
| A local Date object where year >= 0 can be formatted to a common ISO
| 8601 format YYYY-MM-DD with:-
|
| /** Formats a Date to YYYY-MM-DD (local time), compatible with both
| * ISO 8601

According to Wikipedia reference, ISO/IEC 8601:2004 (published) allows
±YYYYY to represent years before 0000 or after 9999 by prior agreement
between the sender and the receiver:

| and ISO/IEC 9075-2:2003 (E) (SQL 'date' type).
| * @param {Date} dateInRange year 0000 to 9999.

<http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=34133>
| Status: Withdrawn

Incidentally, the current revision is SQL:2008.


PointedEars

 

[Garrett Smith]

"Some" implies more than one.

I'm surprised you'd say that.

In logic, "some" means that the phenomenon exists. When proof for the
existence of a phenomenon X is found, the conclusion: "there are some X"
is true.

a) Change the wording. Really?


According to Wikipedia reference, ISO/IEC 8601:2004 (published) allows
±YYYYY to represent years before 0000 or after 9999 by prior agreement
between the sender and the receiver:

Yes, and according to ISO8601:2004, ISO8601:2004 allows Expanded range.

HTML 5 has a mistake with that. Instead of requiring +/- for Expanded
range, HTML5 "parse a month" omits the sign.

http://www.whatwg.org/specs/web-app...on-microsyntaxes.html#parse-a-month-component
| The rules to parse a month component, given an input string and a
| position, are as follows. This will return either a year and a month,
| or nothing. If at any point the algorithm says that it "fails", this
| means that it is aborted at that point and returns nothing.
|
| #1. Collect a sequence of characters in the range U+0030 DIGIT ZERO
| (0) to U+0039 DIGIT NINE (9). If the collected sequence is not at
| least four characters long, then fail. Otherwise, interpret the
| resulting sequence as a base-ten integer. Let that number be the year.

HTML 5 is a draft. That mistake may be fixed and should not be mentioned
in the FAQ.

<http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=34133>
| Status: Withdrawn

Incidentally, the current revision is SQL:2008.

Where can SQL:2008 be downloaded and read for free?

 

[Thomas 'PointedEars' Lahn]

I'm surprised you'd say that.

In logic, "some" means that the phenomenon exists. When proof for the
existence of a phenomenon X is found, the conclusion: "there are some X"
is true.

That is correct. But humans, for whom this text is intended, are not
logical beings. As a result, the semantics of informal human language
more often disagrees with logic than it agrees. For example, "or".

Really?

Yes, really. As an example, you could either change "some" into "one", or
add an "e.g.".

Where can SQL:2008 be downloaded and read for free?

Probably in the same place where SQL:2003 can.


PointedEars

 

[Jeremy J Starcher]

Garrett Smith :


Fine with me, it is enough to warn people for whom it may be a concern.



If 1 BC is removed from the admissible range, I see no need to mention
xs:date.

I would handle it slightly differently and say something along the lines
of:

Year is a range between 1 and 9999[1]


==============

Footnote:
[1] Yes, the standard does include year 0000 as 1 BCE, but it requires
special handling. Coding, documentation and error-checking are much
simpler by removing this particular edge-case. If you need it, please
see the appropriate documentation in xs:date and
http://en.wikipedia.org/wiki/ISO_8601#Years

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Tue, 20 Oct 2009 15:06:12, Garrett Smith

| 4.1 How do I format a Date object with javascript?

The word "do" rather implies a mandatory method - use "can". Other
recently-stated objections apply.

Additionally, perhaps the routine should be converted to a method of the
Date Object, which is what I use.



There should be a recommendation that new Date(0) rather than new Date()
should be used where a Date Object is needed but the present date/time
is not; and that UTC should be used whenever the actual date/time is not
needed.

And, looking ahead, how about using
D.toISOString().split( "T" )[0] // UTC Date
D.toISOString().split(/[TZ]/)[1] // UTC Time
(tested only in current Safari)?

 

[John G Harris]

Year is a range between 1 and 9999[1]

<snip>

To many people 'between' means 2,3,4,...,9998, but not 1 or 9999. Think
of "between the devil and the deep blue sea".

It's much safer to say from 1 to 9999 inclusive.

John

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>,
Wed, 21 Oct 2009 01:34:31, Thomas 'PointedEars' Lahn

According to Wikipedia reference, ISO/IEC 8601:2004 (published) allows
±YYYYY to represent years before 0000 or after 9999 by prior agreement
between the sender and the receiver:

One should read the standard, not a publicly-editable synopsis.

 

[Garrett Smith]

In comp.lang.javascript message <[email protected]
september.org>, Tue, 20 Oct 2009 15:06:12, Garrett Smith

| 4.1 How do I format a Date object with javascript?

The word "do" rather implies a mandatory method - use "can". Other
recently-stated objections apply.

Additionally, perhaps the routine should be converted to a method of the
Date Object, which is what I use.



There should be a recommendation that new Date(0) rather than new Date()
should be used where a Date Object is needed but the present date/time
is not; and that UTC should be used whenever the actual date/time is not
needed.

And, looking ahead, how about using
D.toISOString().split( "T" )[0] // UTC Date
D.toISOString().split(/[TZ]/)[1] // UTC Time
(tested only in current Safari)?

Makes sense.

But buggy in Firefox, as mentioned here:
http://groups.google.com/group/comp.lang.javascript/msg/29d4af96de5aa282

javascript: var d = new Date, b= d.setFullYear(10000);
alert(d.toISOString());

The "+" sign is absent, but should not be, correct?

javascript: alert( Date.parse("+00010-09-30T00:37:35.928Z") )
javascript: alert( Date.parse("-00010-09-30T00:37:35.928Z") )

Both NaN.

Should be a Date with a year +/- 10, if I am not misunderstanding.

What do you get?

I would not be surprised if Webkit guys copy pasted that. In Safari 4,
Windows Vista (530.19.1), I do not have a Date.prototype.toISOString.

 

[Dr J R Stockton]

I would handle it slightly differently and say something along the lines
of:

Year is a range between 1 and 9999

That means years 2, 3, ... 9997, 9998 and no more. And a Year cannot be
a range of years.

Note : "Year is from 1 to 9999" is shorter and expresses what you mean.

I do not agree with the restriction; but at least the wording must
express the facts.

 

[VK]

In comp.lang.javascript message <[email protected]
september.org>, Tue, 20 Oct 2009 15:06:12, Garrett Smith
<[email protected]> posted:

The word "do" rather implies a mandatory method - use "can".  Other
recently-stated objections apply.

Additionally, perhaps the routine should be converted to a method of the
Date Object, which is what I use.

There should be a recommendation that new Date(0) rather than new Date()
should be used where a Date Object is needed but the present date/time
is not; and that UTC should be used whenever the actual date/time is not
needed.

And, looking ahead, how about using
        D.toISOString().split( "T"  )[0]        // UTC Date
        D.toISOString().split(/[TZ]/)[1]        // UTC Time
(tested only in current Safari)?

Makes sense.

But buggy in Firefox, as mentioned here:http://groups.google.com/group/comp.lang.javascript/msg/29d4af96de5aa282

javascript: var d = new Date, b= d.setFullYear(10000);
alert(d.toISOString());

The "+" sign is absent, but should not be, correct?

javascript: alert( Date.parse("+00010-09-30T00:37:35.928Z") )
javascript: alert( Date.parse("-00010-09-30T00:37:35.928Z") )

Both NaN.

Should be a Date with a year +/- 10, if I am not misunderstanding.

What do you get?

I would not be surprised if Webkit guys copy pasted that. In Safari 4,
Windows Vista (530.19.1), I do not have a Date.prototype.toISOString.

Let's make FAQ a wiki? I came with this proposal the last year:
http://groups.google.com/group/comp.lang.javascript/msg/d90ed9af0fed03b5
and it's still ticking:
http://www.wikihost.org/w/javascript_faq/

IMHO with some ego-maniacs around it is the only way to bring it to
the best consensus-reachable form relevant to the actual developers'
needs.

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn posted:

One should read the standard, not a publicly-editable synopsis.

BTDT (fortunately, a Google search for "ISO 8601:2004" got me the PDF
document without paying for it), and I am pretty sure that you of all
people are well-aware that the Standard was correctly cited in Wikipedia.

In particular, ISO 8601:2004 says:

| 4.1.2.4 Expanded representations
|
| If, by agreement, expanded representations are used, the formats shall
| be as specified below. The interchange parties shall agree the additional
| number of digits in the time element year. In the examples below
| it has been agreed to expand the time element year with two digits.
|
| a) A specific day
| Basic format: ±YYYYYMMDD Example: +0019850412
| Extended format: ±YYYYY-MM-DD Example: +001985-04-12
|
| b) A specific month
| Basic format: ±YYYYY-MM Example: +001985-04
| Extended format: not applicable
|
| c) A specific year
| Basic format: ±YYYYY Example: +001985
| Extended format: not applicable
|
| d) A specific century
| Basic format: ±YYY Example: +0019
| Extended format: not applicable
|
| NOTE 4.1.2.4 includes the definition of representations
| that are expanded and have reduced accuracy.


PointedEars

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Wed, 21 Oct 2009 15:45:51, Garrett Smith

In comp.lang.javascript message <[email protected]
september.org>, Tue, 20 Oct 2009 15:06:12, Garrett Smith

| 4.1 How do I format a Date object with javascript?

The word "do" rather implies a mandatory method - use "can". Other
recently-stated objections apply.
Additionally, perhaps the routine should be converted to a method of
the
Date Object, which is what I use.
There should be a recommendation that new Date(0) rather than new
Date()
should be used where a Date Object is needed but the present date/time
is not; and that UTC should be used whenever the actual date/time is not
needed.
And, looking ahead, how about using
D.toISOString().split( "T" )[0] // UTC Date
D.toISOString().split(/[TZ]/)[1] // UTC Time
(tested only in current Safari)?

Makes sense.

But buggy in Firefox, as mentioned here:
http://groups.google.com/group/comp.lang.javascript/msg/29d4af96de5aa282

Absent in Firefox, for those (like me) afraid of versions 3.5.*.

See <URL:http://www.merlyn.demon.co.uk/js-datex.htm#Auto> line 19.

When viewed in Firefox 3.5, how does the yellow column differ from the
one headed Firefox 3.0 ?

A RegExp could alternatively be used to decompose the "ISOString".

javascript: var d = new Date, b= d.setFullYear(10000);
alert(d.toISOString());

The "+" sign is absent, but should not be, correct?

It's overoptimistic to expect the coders and the ECMA 5 committee to
have read the ISO Standard. From Mail received, it seems probable that
they wrote for JSON, and JSON loosely acknowledges ISO. The routine
should have been called toJSONString.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>,
Thu, 22 Oct 2009 01:16:26, Thomas 'PointedEars' Lahn

BTDT (fortunately, a Google search for "ISO 8601:2004" got me the PDF
document without paying for it),

Legally? I got mine from ISO at the same price. They may not have
intended to offer it, but offer it they did. Now they may not.

and I am pretty sure that you of all
people are well-aware that the Standard was correctly cited in Wikipedia.

Only a verbatim cite, reproducing all markings, can be trustworthy.

In particular, ISO 8601:2004 says:

That is not a verbatim cite; it has significant omissions.

 

[Dr J R Stockton]

In comp.lang.javascript message <de31b459-cc77-4872-af8d-d5a66f5015f3@d4
g2000vbm.googlegroups.com>, Wed, 21 Oct 2009 15:57:07, VK

Let's make FAQ a wiki? I came with this proposal the last year:
http://groups.google.com/group/comp.lang.javascript/msg/d90ed9af0fed03b5
and it's still ticking:
http://www.wikihost.org/w/javascript_faq/

IMHO with some ego-maniacs around it is the only way to bring it to
the best consensus-reachable form relevant to the actual developers'
needs.

Something like that was done, extremely badly, at
http://www.wikicodia.com/. It ended up as "This Account Has Been
Suspended Please contact the billing/support department as soon as
possible." The Wayback Machine has three earlier versions too.

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn


Legally?

Probably not. It is a Word document, though.

I got mine from ISO at the same price. They may not have
intended to offer it, but offer it they did. Now they may not.

Lucky one.

Only a verbatim cite, reproducing all markings, can be trustworthy.


That is not a verbatim cite; it has significant omissions.

Adjustment for the shortcomings of plain text messages, and citation
prefixes aside, it *is* a verbatim copy of the entire subsection 4.1.2.4
of ISO 8601:2004(E) (Third Edition, 2004-12-01).

It differs from the original only in that the first `Y' in each line
is underlined in the original but not here, which is hardly a significant
omission.


PointedEars