- From: WeBMartians <webmartians@verizon.net>
- Date: Tue, 24 Feb 2009 20:55:25 -0500
I think the problem with ISO-8601(:2004?) is that while it is precise, total support requires a large code footprint and effort (durations, intervals, compressed formats and so on). I seem to remember that there is some kind of conflict with something in Javascript regarding years that are represented by strings of more than four characters: years preceding 999 BCE (or 1000 BCE?) or subsequent to 9999 CE. -----Original Message----- From: David Singer [mailto:singer@apple.com] Sent: Tuesday, 2009 February 24 15:12 To: WeBMartians; 'Andy Mabbett'; 'WHATWG List' Subject: Re: [whatwg] Dates and coordinates in HTML5 At 13:59 -0500 24/02/09, WeBMartians wrote: >It's back! It won't die! :-) > >Although it can be argued that a standard should not consider the work >required for implementation, many of the trade-offs in reference to >times and dates do indeed take the present state of code into >consideration. > >One reason for not supporting BCE is a disagreement between historians >and, say, astronomers, on how to represent the year immediately >preceding year one. Is it year -1 (1 BCE) or year zero? > >Currently, the text states that all dates and times since the beginning >of the common era (0001-01-01 00:00:00Z) must be supported. Yes, the >Javascript values can specify dates and times before this epoch. >However, there is no way to interrogate the environment as to whether >or not such values can be used with <time>. That would require much >more work. Thus, the limitation of common era. > >I'd love to see support for BCE and even for prolepsis and >non-Gregorian calendars. ...but I do see the "no BCE" compromise as a >workable one. ISO 8601 is quite precise on this issue. Since these are both machine and human-readable, why is this precision a problem? Why would we not use ISO 6709 (Annex H, text string) as the format for location? -- David Singer Multimedia Standards, Apple Inc.
Received on Tuesday, 24 February 2009 17:55:25 UTC