ISO 8601 date format
nick
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.
From <http://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators>
> <time>Z
> <time>±hh:mm or <time>±hhmm
> <time>±hh
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
2000yqz.googlegroups.com>, Tue, 20 Apr 2010 21:28:30, nick
<nic...@fastmail.fm> posted:
>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.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
nick
wrote:
> [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?
> > What do you guys think?
>
> 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___
Stefan Weiss
> 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?
I think if your goal is to clone something, your output should match the
original's, warts and all.
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
--
stefan
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
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Stefan Weiss
> Stefan Weiss wrote:
>
>> 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.
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 ;)
--
stefan
Garrett Smith
> On 24/04/10 03:11, Thomas 'PointedEars' Lahn wrote:
>> 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
comp.lang.javascript FAQ: http://jibbering.com/faq/
Stefan Weiss
> Stefan Weiss wrote:
>> 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"
Which Internet Explorer? I get "" as a result if length is negative (in
any browser), but I think you meant
var lastChar = "foo".substr(-1, 1);
which returns "f" in MSIE, and is indeed not working as described in the
(non-normative) annex. There's no mention of negative values for the
"start" argument on MSDN [0].
I finally did look at the date() function from PHP.js, and they're not
using any negative argument values, so that shouldn't be a compatibility
problem even with Microsoft's idea of substr(). But I agree that due to
the different behavior, substring() is a more portable alternative, and
should be preferred.
[0] http://msdn.microsoft.com/en-us/library/0esxc5wy(v=VS.85).aspx
--
stefan
Garrett Smith
> On 24/04/10 07:35, Garrett Smith wrote:
>> 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
2000yqj.googlegroups.com>, Thu, 22 Apr 2010 17:46:38, nick
<nic...@fastmail.fm> posted:
>On Apr 22, 9:56 am, Dr J R Stockton <reply1...@merlyn.demon.co.uk>
>wrote:
>> [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.
>> 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.
It seems wrong to include "ISO8601" for something non-compliant.
"PHP8601"?
>> 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 ;)
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