ISO 8601 date format

[nick]

Ok, this is a bit off-topic for cljs but I was hoping someone here
might know the answer.

After reading this:

http://www.w3.org/TR/NOTE-datetime

"TZD = time zone designator (Z or +hh:mm or -hh:mm)"
"1994-11-05T08:15:30-05:00"

I'd say that ISO 8601 formatted dates should have a colon between the
hours and minutes in the time zone designator, right?

It looks like PHP got this wrong:

http://www.php.net/manual/en/class.datetime.php

ISO-8601 (example: 2005-08-15T15:52:01+0000)
const string DateTime::ISO8601 = Y-m-d\TH:i:sO ;
O Difference to Greenwich time (GMT) in hours Example: +0200

What's going on here? Did PHP get this wrong? If so, I wonder how I
should proceed with a PHP date formatting clone in javascript... keep
the incorrect behavior from PHP, or follow the standard? What do you
guys think?

 

[Sean Kinsey]

Ok, this is a bit off-topic for cljs but I was hoping someone here
might know the answer.

After reading this:

http://www.w3.org/TR/NOTE-datetime

  "TZD  = time zone designator (Z or +hh:mm or -hh:mm)"
  "1994-11-05T08:15:30-05:00"

I'd say that ISO 8601 formatted dates should have a colon between the
hours and minutes in the time zone designator, right?

Both are valid.

 

[Adam Harvey]

Ok, this is a bit off-topic for cljs but I was hoping someone here might
know the answer.

FWIW, comp.lang.php may have been a better destination, since it's really
a question about the quirks of a particular PHP function.

It looks like PHP got this wrong:

http://www.php.net/manual/en/class.datetime.php

ISO-8601 (example: 2005-08-15T15:52:01+0000) const string
DateTime::ISO8601 = Y-m-d\TH:i:sO ; O Difference to Greenwich time
(GMT) in hours Example: +0200

What's going on here? Did PHP get this wrong? If so, I wonder how I
should proceed with a PHP date formatting clone in javascript... keep
the incorrect behavior from PHP, or follow the standard? What do you
guys think?

Sean has already noted that ISO 8601 time zone designators are valid both
with and without the colons. PHP's date function also provides the P
format specifier which explicitly includes the colon in the time zone.

Without being absolutely sure, I'd suspect that the reason for O behaving
that way in the first place would be because date() would have been
developed initially to target RFC 822 compliant dates (as used
extensively in HTTP), which don't include a colon in the time zone
designator.

At any rate, if your goal is to intentionally replicate PHP's date
formatting functionality, you're probably best off sticking to how PHP
actually does it, warts and all -- anything else will likely lead to more
confusion.

Adam

 

[nick]

FWIW, comp.lang.php may have been a better destination, since it's really
a question about the quirks of a particular PHP function.

Ideally yes, but every time I look at that NG I shudder at the thought
of posting there...

Sean has already noted that ISO 8601 time zone designators are valid both
with and without the colons.

This is what I needed to know. Luckily it makes for an easy solution
-- Thanks, both of you

[...]
At any rate, if your goal is to intentionally replicate PHP's date
formatting functionality, you're probably best off sticking to how PHP
actually does it, warts and all -- anything else will likely lead to more
confusion.

I think you're right. Thanks for the advice!

-- Nick

 

[Dr J R Stockton]

In comp.lang.javascript message <fadf01fc-121f-470a-818a-f2ef42c69935@8g
2000yqz.googlegroups.com>, Tue, 20 Apr 2010 21:28:30, nick

After reading this:

http://www.w3.org/TR/NOTE-datetime

"TZD = time zone designator (Z or +hh:mm or -hh:mm)"
"1994-11-05T08:15:30-05:00"

I'd say that ISO 8601 formatted dates should have a colon between the
hours and minutes in the time zone designator, right?

Partly so. That form is correct, though TZD designates the Offset and
not the Zone. Read on.

It looks like PHP got this wrong:

http://www.php.net/manual/en/class.datetime.php

ISO-8601 (example: 2005-08-15T15:52:01+0000)
const string DateTime::ISO8601 = Y-m-d\TH:i:sO ;
O Difference to Greenwich time (GMT) in hours Example: +0200

That should really be to UTC. And it is not in hours - 200 hours is
8 1/3 rimes round the world - but in hours & minutes.

What's going on here? Did PHP get this wrong? If so, I wonder how I
should proceed with a PHP date formatting clone in javascript... keep
the incorrect behavior from PHP, or follow the standard? What do you
guys think?

On such a matter, one should not think. Instead, one should read the
current version of ISO 8601.

ISO 8601:2004(E) Section 4.2.5.1 "Difference between local time and UTC
of day" does include
Basic format: ±hhmm Example: +0100
Extended format: ±hh:mm Example: +01:00
so the offset can indeed be expressed in either manner.

*B*U*T* ISO 8601:2004(E) Section 4.2.5.2 "Local time and the difference
from UTC" includes
Basic format: hhmmss±hhmm Example: 152746+0100
Extended format: hh:mm:ss±hh:mm Example: 15:27:46+01:00

Clearly "basic" and "extended" each cover the whole lot, and are not to
be mixed. So www.php.net is wrong.

You should provide a version which is correct, and if necessary an
alternative compatible with www.php.net.

My DATE2 provides, AFAIR, all reasonable formats and useful
combinations.



Please use a fuller name and a distinctive signature - you should not
assume that you are the only possible nick.

 

[nick]

[nick:]

ISO-8601 (example: 2005-08-15T15:52:01+0000)
const string DateTime::ISO8601 = Y-m-d\TH:i:sO ;
O  Difference to Greenwich time (GMT) in hours  Example: +0200

That should really be to UTC.  And it is not in hours - 200 hours is
8 1/3 rimes round the world - but in hours & minutes.

Good catch on the hours. Why the distinction between GMT and UTC?

On such a matter, one should not think.  Instead, one should read the
current version of ISO 8601.

In fairness, reading that document from front to back (I just did)
does require one to think, or at least to concentrate. Check out this
monstrosity of a sentence:

| By mutual agreement of the partners in information interchange,
| duration may be expressed in conformity with the format used
| for time-points, as specified in 5.2.1, 5.2.2, 5.2.3, 5.3.1.5
| and 5.4, where the formats of 5.4 are restricted for the date
| component to the formats in 5.2.1 and for the time-of-the-day
| component to the formats in 5.3.1.1 through 5.3.1.3.

Even if I had already read this I think I would have liked to get a
second opinion.

ISO 8601:2004(E) Section 4.2.5.1 "Difference between local time and UTC
of day" does include
        Basic format:           ±hhmm   Example: +0100
        Extended format:        ±hh:mm  Example: +01:00
so the offset can indeed be expressed in either manner.
Agreed.

*B*U*T* ISO 8601:2004(E) Section 4.2.5.2 "Local time and the difference
from UTC" includes
        Basic format:           hhmmss±hhmm     Example: 152746+0100
        Extended format:        hh:mm:ss±hh:mm  Example: 15:27:46+01:00

Clearly "basic" and "extended" each cover the whole lot, and are not to
be mixed.  Sowww.php.netis wrong.

I also get the impression that they weren't supposed to be mixed. SS
5.4.2 (d) of that document says:

| [T]he expression shall either be completely in basic format,
| in which case the minimum number of separators necessary
| for the required expression is used, or completely in
| extended format, in which case additional separators shall
| be used in accordance with 5.2 and 5.3.

The title of 5.4.2 is "Representations other than complete." What do
you suppose that means?

You should provide a version which is correct, and if necessary an
alternative compatible withwww.php.net.

Ok, but with different names from the PHP constant.. maybe ISO8601_E
and ISO8601_B. ISO8601 keeps the PHP behavior.

My DATE2 provides, AFAIR, all reasonable formats and useful
combinations.

Cool, so you should be able to tell me if I've done a good job when I
finish mine

Please use a fuller name and a distinctive signature - you should not
assume that you are the only possible nick.

I'll think about it...

-- Nick___

 

[nick]

I think if your goal is to clone something, your output should match the
original's, warts and all.

I think so too. I'm keeping to the original behavior as much possible
and adding a few new things for strict standards compliance.

By the way, there's a project which is trying to port all PHP functions
to JS, for some reason. I didn't look at their code, but you may get
some inspirations from their implementation of the date() function:

http://phpjs.org/functions/index

I've seen it, it looks interesting. Part of the reason I'm doing this
is to sharpen my javascript skills, so I don't want to borrow too much
from other sources before I try to do it myself... I'd rather try it
first and then see how my approach compares to what others have done.
My date thing is basically done as far as actually formatting the
dates, I'm just going through and cleaning things up at this point.

-- Nick

 

[Thomas 'PointedEars' Lahn]

By the way, there's a project which is trying to port all PHP functions
to JS, for some reason. I didn't look at their code, but you may get
some inspirations from their implementation of the date() function:

http://phpjs.org/functions/index

Like how NOT to do it? It looks like the expected result of a million code
monkeys educated probably by w3schools.com, adding to PPK's misconceptions,
starting with undeclared `that = this' when `that' is not ever used, and
substr() calls.


PointedEars

 

[Garrett Smith]

Stefan Weiss wrote:

[...]

As I said, I didn't look at the code. Undeclared and unused variables?
That doesn't look good. I don't have a problem with the substr() calls.
That method is pretty well supported, and since they say they're porting
PHP functions to *JavaScript* (tm), substr() should be available

I did not immediately notice a call to String.prototype.substr, however
that method should be avoided. The did not use that method in their
`substr` method.

ECMA-262 Non-normative Annex defines String.prototype.substr

| The substr method takes two arguments, start and length, and returns
| a substring of the result of converting this object to a string,
| starting from character position start and running for length
| characters (or through the end of the string is length is undefined).
| If start is negative, it is treated as (sourceLength + start) where
| sourceLength is the length of the string. The result is a string
| value, not a String object.

Testing that with an start=-1 and length=-1, the last character of a
string can be obtained.

var lastChar = "foo".substr(-1, -1);
alert(lastChar);

Internet Explorer Result:
"foo"

 

[Garrett Smith]

Stefan Weiss wrote:

[...]

Which Internet Explorer? I get "" as a result if length is negative (in
any browser), but I think you meant

You're right, sorry. However it is clear that JScript does not follow
the spec's non-normative recommendation.

IE7, using JScript 5.7:
"foo".substr(-1)
"foo"

"foo".substr(-1, -1)
""

String.prototype.slice works consistently as specified.

 

[Dr J R Stockton]

In comp.lang.javascript message <21e70fcb-f302-49f6-a8b5-7a2834a77928@5g
2000yqj.googlegroups.com>, Thu, 22 Apr 2010 17:46:38, nick

[nick:]

ISO-8601 (example: 2005-08-15T15:52:01+0000)
const string DateTime::ISO8601 = Y-m-d\TH:i:sO ;
O  Difference to Greenwich time (GMT) in hours  Example: +0200

That should really be to UTC.  And it is not in hours - 200 hours is
8 1/3 rimes round the world - but in hours & minutes.

Good catch on the hours. Why the distinction between GMT and UTC?

The distinction is that GMT had 86400 seconds per day every day, and to
agree with the Sun those seconds vary slightly in length, whereas UTC
uses SI seconds (derived from Caesium) and occasionally needs to add (or
subtract) one at the end of a half-year. The term GMT is technically
obsolete AIUI, and UT is a modern equivalent. But UT looks like a typo
for UTC. IIRC, by law UK time is GMT; but the time signals are UTC.
The difference between UT & UTC is not allowed to exceed 0.9 seconds.

The USA prefers not to use GMT because their Greenwich is disreputable &
in the wrong longitude.

The title of 5.4.2 is "Representations other than complete." What do
you suppose that means?

That's 4.4.5 in my 3rd Edition of 2004 : is yours earlier or later?
Either it's 2000 (1998 had no 5.4.2) or it's later than 2004 (in which
case I want a PDF of it!) (and someone should tell Wikipedia!).

It means when some of the full YYYYMMDDThhmmss or YYYY-MM-DDThh:mm:ss is
omitted.

Ok, but with different names from the PHP constant.. maybe ISO8601_E
and ISO8601_B. ISO8601 keeps the PHP behavior.

It seems wrong to include "ISO8601" for something non-compliant.
"PHP8601"?

Cool, so you should be able to tell me if I've done a good job when I
finish mine

DATE2 Format String "a, D o Y Y-r-D Y-O X-WV-C YMD" can give
"Mon, 31 Dec 2001 2001-xii-31 2001-365 2002-W01-1 20011231"
in which the "xii" is a single Unicode character. For three-character
xii, set DATE2.Mnth.

new DATE2().getXEasterSunday() -> Sun, 2010 Apr 04, 00:00:00 GMT
or Sun, 2010 Apr 04, 00:00:00 GMT+0100
// for UTC, change G to U in DATE2.Fmt