On Fri, 25 Mar 2011, J.H. wrote:
> On 03/24/2011 01:19 PM, Jakub Narebski wrote:
>> On Thu, 24 Mar 2011, Kevin Cernekee wrote:
>>> 4) IE6 does not seem to like ISO 8601 format:
>>>
>>> x = new Date("2011-03-09T03:29:09Z");
>>>
>>> This sets all fields to NaN. I suspect that getTime() values
>>> (milliseconds since 1970-01-01) are more portable.
>>
>> Do you mean using epoch in title attribute, or fallback to parsing
>> ISO 8601 UTC format with regexps?
>
> Parsing it with regexps is doable if completely inelegant, that said
> this is Javascript...
>
> Looky that MS provides Virtual PC images for compat testing for IE6
> http://www.microsoft.com/downloads/en/details.aspx?FamilyID=21eabb90-958f-4b64-b5f1-73d0a413c8ef&displaylang=en
>
> Ok reading through the documentation I can find for MS and their
> Date.parse (
> http://msdn.microsoft.com/en-us/library/dctx55bc(v=VS7.1).aspx ) and
> some quick experimentation:
>
> 2011-03-09 - breaks
> 2011/03/09 - works
I really don't like using '/' as a separator; not only this is not
ISO-8601, but it is easy to confuse with insane American way of
writing dates with MM/DD/YYYY (day in the middle).
> 2011/03/09T01:01:01 - works, sorta - the hour comes out as 10 vs. 01
> 2011/03/09 01:01:01 - works, hour is correct
> 2011/03/09 01:01:01Z - works and seems to get the TZ correct
> 2011/03/09T01:01:01Z - breaks
If it worked in all (or almost all) web browsers with
2011-03-09 01:01:01Z - works and seems to get the TZ correct
then I would say go for it - this variant of ISO-8601 with ' ' instead
of 'T' to separate date part from time part is more human-readable.
> Not really sure what the "right" way to fix this is going to end up
> being. Suppose our options are:
>
> 1) Try and find a format that is generally accepted and parseable on all
> the browsers
> 2) Declare IE6 an unsupported browser
> 3) Trap what browser we are on and do a regex parsing of the string and
> do appropriate sets or a more verbose format that works everywhere
If web browser returned undefined value if they can't parse date, then
we could do regexp parsing based on this, not on user-string (which is
in most cases wrong solution).
> 4) Use a regex and sets for every browser.
> 5) Switch all the embedded times over to epochs in the title=""'s
>
> 4 is probably the "most" right that I can see of those options, and
> avoids possible other browser inconsistencies with respect to date
> parsing. I'm going to code that up (it shouldn't be terribly
> complicated), unless someone likes one of the other ideas better.
> Suppose we could even go down the more complicate microformat route and
> just write some code to parse that, just more complicated all the way
> around.
Right.
> 5 has the appeal that everything handles the epoch correctly, but it
> does have the downside of being less readable in the html code (and
> shifts us slightly further away from the accepted "standard" of the
> microcode formats)
Well, we could always use non-standard 'epoch' attribute, or something...
--
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html