Re: [whatwg] Expanding datetime
On Jul 30, 2008, at 23:29, Benjamin Hawkes-Lewis wrote: Wrong. Microformats may also be used to mark up events that happened in the past and people who are dead. For example: http://en.wikipedia.org/wiki/Walt_Disney What use case is served by marking up Walt Disney's birthday as bday? Surely people aren't supposed to export Walt Disney's contact information to their address book app and have it remind them to congratulate Walt on his birthday. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Expanding datetime
Believe it or not, Yes! Consider the couple to be congratulated on their gazillionth anniversary. Is that diamond, gold, platinum? Whatever it is, if your date time system is limited to epoch 1970, you're out of luck. That's why I claim that restrictions (rigorously documented) are OK as long as they are not ludicrous - ludicrous being a gray area, rather than a sharp line - 1970 definitely is, 1900 is probably OK, 1582 is interesting and far less ludicrous, while - is very safe but maybe ludicrous in other ways (prolepsis, locales...). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Henri Sivonen Sent: Thursday, 2008 July 31 04:26 To: Benjamin Hawkes-Lewis Cc: 'WHATWG List'; Ian Hickson Subject: Re: [whatwg] Expanding datetime On Jul 30, 2008, at 23:29, Benjamin Hawkes-Lewis wrote: Wrong. Microformats may also be used to mark up events that happened in the past and people who are dead. For example: http://en.wikipedia.org/wiki/Walt_Disney What use case is served by marking up Walt Disney's birthday as bday? Surely people aren't supposed to export Walt Disney's contact information to their address book app and have it remind them to congratulate Walt on his birthday. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Expanding datetime
Henri Sivonen wrote: What use case is served by marking up Walt Disney's birthday as bday? Surely people aren't supposed to export Walt Disney's contact information to their address book app and have it remind them to congratulate Walt on his birthday. Again, you're thinking entirely in terms of social networking and not in terms of education and intellectual curiosity. I'd imagine more probable applications would be building (or searching) collections of biographical or event data from multiple sources. Let's say you have an application for constructing chronologies, and you're constructing a chronology of (say) the history of animation. You could drag and drop Walt's birthday onto the chronology. Look at this lesson plan for example: Have a collection of images of famous people use as a resource show to the children and discuss who they are and why they are famous. Have a selection of people from the past and present. Use www.Google.co.uk to find images. You could see if they could try and put them in a timeline. http://www.supporting-ict.co.uk/weblinks/historyks1.htm (If you look around, you'll find plenty of timeline-oriented approaches to the past.) Or, maybe you're building a database of animators with film samples. You could pull microformatted biographical information out from across the web and add it to your page. Or, maybe you're a journalist who needs to construct an on this day article. You search for stuff that happened on Disney's birthday, and come across Disney's biography that way. Anyhow, whether such applications of microformats fits how you imagine or would like to dictate how people use microformatted data, TIME as defined cannot cover how microformats are already applied, so let us not pretend that it does. You're free to argue that trying to encode such information is pointless, but that's an argument you'd want to take up with the microformats community and one I cannot support. -- Benjamin Hawkes-Lewis
Re: [whatwg] Expanding datetime
WeBMartians wrote: Believe it or not, Yes! Consider the couple to be congratulated on their gazillionth anniversary. Is that diamond, gold, platinum? Whatever it is, if your date time system is limited to epoch 1970, you're out of luck. That's why I claim that restrictions (rigorously documented) are OK as long as they are not ludicrous - ludicrous being a gray area, rather than a sharp line - 1970 definitely is, 1900 is probably OK, 1582 is interesting and far less ludicrous, while - is very safe but maybe ludicrous in other ways (prolepsis, locales...). For what it's worth, the proposed spec already defines rigorous limits Dates before the year 0 or after the year can't be represented as a datetime in this version of HTML. http://www.w3.org/html/wg/html5/#dates -- Benjamin Hawkes-Lewis
Re: [whatwg] Expanding datetime
On Wed, 23 Apr 2008, Ernest Cline wrote: The range of valid datetime strings is a subset of those specified by ISO 8601. Most of the unused formats have been rejected on the grounds of simplicity of parsing, but a format (I think added in ISO 8601:2004, but it may have been earlier) offers a gain in utility that would not be unduly complicated to implement. Datetime is current limited to years in the range of - . Additional digits could be added to the year and still keep the string a valid ISO 8601 string, provided that the number to be added is agreed to and the added digits are always preceded by either a + or -. For example, if one digit is added, then the day before -01-01 could be represented as -1-12-31. From a practical viewpoint, being able to specify dates before January 1, 1 BC (Gregorian) would allow for historical dates not currently available to be specified in markup of documents concerning history. The Y10K problem can also be pushed back by this, but is of only theoretical importance. Dates outside the near past and near future really aren't in any of the use cases for date types in HTML5 so far. For far away dates, use cases almost always end up being far more complicated, requiring things like range support, vague date support (e.g. just the month and year, or just the year, or a range of days in a month and year), explicit calendar support, etc. So supporting those dates really isn't a problem that we need to solve, at least as far as addressing the use cases put forth so far. Note that supporting old dates gets especially dicey given that calendars changed to the Gregorian calendar at different dates in different countries, so you have to include geographic information as well to convert old dates into Gregorian-equivalent dates. This is really an area of complexity that we do not want to specify in HTML5. On Thu, 24 Apr 2008, Henri Sivonen wrote: How do proleptic Gregorian dates before the Common Era fit into any of the use cases that states are used for in HTML? Insertion and deletion dates are contemporary. Date form widgets are meant for airline and hotel reservations and, hence, need to pick dates from the near future. The time element is meant for microformats, which means that it will be used for encoding current or near-future events dates. Right. On Fri, 25 Apr 2008, Christoph P�per wrote: What about, for instance, adjustable timelines at history websites or virtual skies at astronomic sites? Neither of these would likely use type=date. Timelines probably would rather use logarithmic year selectors (e.g. using type=range), and virtual skies for dates far away will typically use Julian dates (which are more like type=number step=any). On Thu, 24 Apr 2008, Charles wrote: Genealogy would seem to be another relatively popular use. Genealogy's use of dates is far, far more complex and involved for old dates than anything type=date can do. On Fri, 25 Apr 2008, Henri Sivonen wrote: I think the questions are: * Are there use cases for entering proleptic Gregorian dates before the Common Era in a Web form (input type=date)? * Are there use cases for representing proleptic Gregorian dates before the Common Era in a way that moving the data to a calendar app (time)? * Are there use cases for annotating document modifications with proleptic Gregorian dates before the Common Era (ins/del)? I think the answer to the ins/del case is no. The future is intended for tracking changes in computer documents, and all historical documents have been migrated to computer documents in the Common Era. I think the answer to the calendar at case is in no. The calendar app case is about planning future events. You don't need time markup when writing about historic events before the Common Era--in particular, if you write about events that are referred to by their Julian dates. As for the form case, it seems implausible to me that sites about the history of urban planning or ecology would require users to enter dates that are more precise than to the year. In the case of sites about historic events, it also seems implausible that users would be competent to enter precise proleptic Gregorian dates for searching events that occurred when the Julian Calendar was in use (or in other locales a calendar that *looks* different, too). To make calculations with the precision of a year, the user interface could use a form field that takes a number and sidestep the issue of converting the year two seconds or milliseconds. The historic astronomy case seems awfully narrow to justify making native date widgets deal with BCE dates. I agree with all these points. On Thu, 24 Apr 2008, Lachlan Hunt wrote: Such dates do not need to be published on the web in machine readable readable formats. How often to do you need to book a flight, or add an event to your
Re: [whatwg] Expanding datetime
I feel uneasy about this Gregorian bias in dates, although I use Gregorian calendar myself. It seems Gregorian dates do not require specifying the datetime attribute but all other dates do (like Arabic lunar, Jewish, Thai, Ethiopic, whatever). It would be much better if the algorithm were locale-dependent, although this would probably require having HEAD META[NAME=LOCALE]. I understand this idea could be postponed indefinitely or rejected in the present state of affairs; which option would you choose? I mean, converting the dates the author regularly uses to Gregorian would require support from the editor or postprocessor. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, July 30, 2008 1:13 PM To: 'WHATWG List' Subject: Re: [whatwg] Expanding datetime
Re: [whatwg] Expanding datetime
Ian Hickson wrote: On Thu, 24 Apr 2008, Henri Sivonen wrote: How do proleptic Gregorian dates before the Common Era fit into any of the use cases that states are used for in HTML? Insertion and deletion dates are contemporary. Date form widgets are meant for airline and hotel reservations and, hence, need to pick dates from the near future. The time element is meant for microformats, which means that it will be used for encoding current or near-future events dates. Right. Wrong. Microformats may also be used to mark up events that happened in the past and people who are dead. For example: http://en.wikipedia.org/wiki/Walt_Disney If HTML5 does not provide a way to specify datetimes BC, then the microformats community would be left in the boat they're already in of trying to fudge markup to encode datetimes BC. Little gained, really. Regardless of what elements are added to HTML5, I believe HTML5 needs a simple extension point where microformats can insert machine-parsable equivalents and expansions of human friendly data. Data types are by no means limited to those already covered by the HTML5 proposals: http://microformats.org/wiki/machine-data XHTML2 provides such an extension point with the (confusingly named) CONTENT attribute: http://www.w3.org/TR/xhtml2/mod-metaAttributes.html#adef_metaAttributes_content Such an extension point could meet the use-case of making datetimes BC extractable and also any use-case for far-future datetimes without requiring HTML5 to explicit specify calendar APIs for them. DATA-* is not yet such an extension point, since it is only to be used for private scripts not public metadata: http://www.w3.org/html/wg/html5/#custom Obviously, it would be /ideal/ if DATETIME could actually handle a range of dates useful for educational and research purposes as well as social networking and business and if schoolkids and academics didn't have to fall back on extension points and homebrew code, but I accept that it would inevitably be more work to spec and probably for user agent developers to ultimately implement. -- Benjamin Hawkes-Lewis
Re: [whatwg] Expanding datetime
[Warning: begin tirade, diatribe, fulmination, harangue, jeremiad, and/or philippic] At the very least, ensure that the range of times (dates, durations, intervals and times-of-day) and the granularity are well and rigorously specified. Ensure, also, that there is a Javascript mechanism to alarm, mechanically, when such element values exceed the specified envelope (I do not see such in the current text). If the browser cannot handle a datetime string of -0548-11-22 18:23:46,03276548901+3 (other-epochal, proleptic, locale-dependent and, I'm certain, annoying in several other respects), just make sure Javascript does something predictable and explicit. I can see arguments on both sides of the question: + Microformats and extra-UNIXian-epochs are needed and there are business cases Hawkes-Lewis alludes to such with the Disney link (http://en.wikipedia.org/wiki/Walt_Disney) Read: Copyright Issues - It's so painful as to require a document comparable to the entire HTML5 specification Previous postings have commented on datetime strings and ISO-8601 and look at that awful mess I used, above, as an example Strangely, there exists an argument for a crippling of capabilities. It goes like this: If a browser's Javascript is limited, JS files can support microformats, proleptic dates, Before-Common-Era dates, unique epochs and so on. However, the creation of such utilities will be hindered if the needs-case is nebulous. Failing to explicitly specify the HTML5 envelope will only increase that ambiguity (Well, it works most of the time, so why bother?). The question then becomes, Is the specification properly limited or ludicrous? I would claim that an epoch of 1970 (the traditional, UNIX epoch) is ludicrous just because so many luminaries started their existence before that moment (for example, me - ahem). On the other hand, I could understand a requirement that an epoch of no later than 1900, while limited, is at least proper (even in light of some locales' not adopting the Gregorian calendar until the 1930s). Just don't hinder the needs-case for somebody building the JS files (I repeat myself, but I did warn that this would be tediously hortatory). [end tirade - Thank you for your patience] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin Hawkes-Lewis Sent: Wednesday, 2008 July 30 16:29 To: Ian Hickson Cc: 'WHATWG List' Subject: Re: [whatwg] Expanding datetime Ian Hickson wrote: On Thu, 24 Apr 2008, Henri Sivonen wrote: How do proleptic Gregorian dates before the Common Era fit into any of the use cases that states are used for in HTML? Insertion and deletion dates are contemporary. Date form widgets are meant for airline and hotel reservations and, hence, need to pick dates from the near future. The time element is meant for microformats, which means that it will be used for encoding current or near-future events dates. Right. Wrong. Microformats may also be used to mark up events that happened in the past and people who are dead. For example: http://en.wikipedia.org/wiki/Walt_Disney If HTML5 does not provide a way to specify datetimes BC, then the microformats community would be left in the boat they're already in of trying to fudge markup to encode datetimes BC. Little gained, really. Regardless of what elements are added to HTML5, I believe HTML5 needs a simple extension point where microformats can insert machine-parsable equivalents and expansions of human friendly data. Data types are by no means limited to those already covered by the HTML5 proposals: http://microformats.org/wiki/machine-data XHTML2 provides such an extension point with the (confusingly named) CONTENT attribute: http://www.w3.org/TR/xhtml2/mod-metaAttributes.html#adef_metaAttributes_content Such an extension point could meet the use-case of making datetimes BC extractable and also any use-case for far-future datetimes without requiring HTML5 to explicit specify calendar APIs for them. DATA-* is not yet such an extension point, since it is only to be used for private scripts not public metadata: http://www.w3.org/html/wg/html5/#custom Obviously, it would be /ideal/ if DATETIME could actually handle a range of dates useful for educational and research purposes as well as social networking and business and if schoolkids and academics didn't have to fall back on extension points and homebrew code, but I accept that it would inevitably be more work to spec and probably for user agent developers to ultimately implement. -- Benjamin Hawkes-Lewis
Re: [whatwg] Expanding datetime
-Original Message- From: Henri Sivonen [EMAIL PROTECTED] The historic astronomy case seems awfully narrow to justify making native date widgets deal with BCE dates. Native date widgets already need to deal with BCE dates at the DOM level as they are well within the range of a DOMTimeStamp. In ECMAScript the range of years for which any time in the year can be represented is from 283,459 BCE to 287,398 AD. What is being proposed is allowing a document to specify such times in the document without having to resort to scripting by expanding the range of values the datetime attribute can represent. The draft is already proposing making changes to the existing HTML 4 specification of datetime by allowing only the date or the time to be given instead of the full date and time, so datetime is already being proposed to be changed, so the question therefore is not should we change datetime, but rather what other changes would be worth incorporating so as to avoid having to change datetime a second time. (For instance, since DOMTimeStamp uses a millisecond granularity, allowing datetime to specify milliseconds may be of use as well.)
Re: [whatwg] Expanding datetime
We're in a situation, here, where the HTML specification is about to say You can specify a value, but, maybe, just maybe, you cannot show that value ... Oh, yes, AND we're not even going to tell you when that 'maybe' is in effect! If you can spec a value, you should be able to present it. Imagine setting a Javascript integer to -123456789 but not being able to toString() it. Imagine setting a background-color: Red; but not having it show (or show as a different color). Imagine the howling and complaining about that! The generation of the proper datetime string is easy, technically. Yes, Apple, Microsoft, Mozilla and Opera will have to ensure that the values can be generated, if such test cases do not exist already. The datetime string to value conversion is going to cause some more effort. Can the standard state that datetime strings support ISO 8601:2004 and leave it at that? (just a thought) At the very least, have a MINDate MAXDate (a la the C limits.h) constant. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ernest Cline Sent: Friday, 2008 April 25 13:09 To: Henri Sivonen; Charles McCathieNevile Cc: WHATWG List Subject: Re: [whatwg] Expanding datetime -Original Message- From: Henri Sivonen [EMAIL PROTECTED] The historic astronomy case seems awfully narrow to justify making native date widgets deal with BCE dates. Native date widgets already need to deal with BCE dates at the DOM level as they are well within the range of a DOMTimeStamp. In ECMAScript the range of years for which any time in the year can be represented is from 283,459 BCE to 287,398 AD. What is being proposed is allowing a document to specify such times in the document without having to resort to scripting by expanding the range of values the datetime attribute can represent. The draft is already proposing making changes to the existing HTML 4 specification of datetime by allowing only the date or the time to be given instead of the full date and time, so datetime is already being proposed to be changed, so the question therefore is not should we change datetime, but rather what other changes would be worth incorporating so as to avoid having to change datetime a second time. (For instance, since DOMTimeStamp uses a millisecond granularity, allowing datetime to specify milliseconds may be of use as well.)
Re: [whatwg] Expanding datetime
-Original Message- From: WeBMartians [EMAIL PROTECTED] Can the standard state that datetime strings support ISO 8601:2004 and leave it at that? (just a thought) Considering the considerable number of formats that ISO 8601:2004 encompasses, I don't think that would be a good idea. The following format possibilities for specifying instants in time, while acceptable to ISO 8601:2004 would not be worth adding to HTML 5 under any use case I can imagine. I really can't see why they bothered with the century format except as supplemental field for pre Y2J applications that used a 2 digit year field. Decimal minutes and hours are allowed in ISO 8601:2004, but lead to problems with rounding once one gets to increments smaller than 0.0001 min and 0.1 h respectively, so should probably not be adopted. The alternate ways of representing 1985-04-12: the ordinal date (1985-102) and the week date (1985-W15-5) don't offer anything that would justify the extra complexity that would be required of the parser. In case the specification ever develops a use case for a comma separated list of datetime values, then the use of comma as an alternate to the period for the decimal point should not be allowed. HTML 4 currently allows only: -##-##T##:##:##Z -##-##T##:##:##+##:## -##-##T##:##:##-##:## These three formats are a subset of those suggested by the W3C datetime note [1] which itself is a subset of the choices available under ISO 8601. The HTML 5 draft currently extends this to allow: * leaving out the seconds (valid under the W3C datetime note) * adding a decimal point and one or more digits for fractional seconds (valid under the W3C datetime note) * specifying just the date (valid under the W3C datetime note) * specifying just the time (valid under ISO 8601, but not the W3C datetime note) * replacing the T separator between the time and date with whitespace (NOT VALID under ISO 8601) * including some optional whitespace in some specific places (NOT VALID under ISO 8601) Unless allowing the whitespace is needed to back standardize an existing implementation's handling of ins/del, it should be removed from the draft as it is not ISO 8601 compliant and complicates the job of the parser, though I grant it does improve the human readability slightly. As a side issue, unless attribute values are restricted to ISO/IEC 656 characters, ISO 8601 appears to call for also accepting U+2010 HYPHEN as a separator between the fields of a date value, and U+2212 MINUS for the sign in a time zone designator or extended year representation. The following is a list of steps for a parser that accepts a wide range of valid ISO 8601 datetime formats, assuming that extended years are of the format ±Y and that at most 3 digits are allowed after the FULL STOP in the seconds. Variables date, time, and zone are booleans for whether a date, time, or timezone was present in the designation. Variables year, month, day, hour, minute, second, millisecond, zonehour, and zoneminute contain the correct results, but range checking for nonsense values as 2007-02-29 or even 2007-13-42 is not done, nor is converting them to value stored in the DOM. 0. Set month and day to 1; set hour, minute, second, and millisecond to 0; set date, time, and timezone to invalid; advance to the first non-whitespace character. 1. If the next character is not PLUS, MINUS, or HYPHEN-MINUS, skip to step 5. 2. If the next character is not PLUS, set year to -1, else set year to 1. 3. Advance 1 character; if the next five characters are not in the set DIGIT ZERO .. DIGIT NINE, abort as invalid. 4. Set date to valid; multiply year by the value given by the next five characters; advance 5 characters; skip to step 7. 5. If the next four characters are not in the set DIGIT ZERO .. DIGIT NINE, skip to step 17. 6. Set date to valid; set year to the value given by the next four characters; advance 4 characters. 7. If the next character is whitespace, COMMA, or end of string, end as valid. 8. If the next character is not HYPHEN or HYPHEN-MINUS, abort as invalid. 9. If the next two characters are not in the set DIGIT ZERO .. DIGIT NINE, abort as invalid. 10. Set month to the value given by the next two characters; advance 2 characters. 11. If the next character is whitespace, COMMA, or end of string, end as valid. 12. If the next character is not HYPHEN or HYPHEN-MINUS, abort as invalid. 13. If the next two characters are not in the set DIGIT ZERO .. DIGIT NINE, abort as invalid. 14. Set day to the value given by the next two characters; advance 2 characters. 15. If the next character is whitespace, COMMA, or end of string, end as valid. 16. If the next character is not LATIN CAPITAL LETTER T abort as invalid. 17. If the next two characters are not in the set DIGIT ZERO .. DIGIT NINE, abort as invalid. 18. Set time to valid; set hour to the value given by the next two characters; advance 2 characters.
Re: [whatwg] Expanding datetime
On Apr 24, 2008, at 10:58 , Henri Sivonen wrote: How do proleptic Gregorian dates before the Common Era fit into any of the use cases that states are used for in HTML? *dates* are used... -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Expanding datetime
Ernest Cline wrote: From a practical viewpoint, being able to specify dates before January 1, 1 BC (Gregorian) would allow for historical dates not currently available to be specified in markup of documents concerning history. Such dates do not need to be published on the web in machine readable readable formats. How often to do you need to book a flight, or add an event to your calendar that far back in the past? ...The Y10K problem can also be pushed back by this, but is of only theoretical importance. There are still 7992 years before we need to have a Y10K solution implemented. Thus we can safely leave it to to future generations to solve. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Expanding datetime
-Original Message- From: Lachlan Hunt [EMAIL PROTECTED] Ernest Cline wrote: From a practical viewpoint, being able to specify dates before January 1, 1 BC (Gregorian) would allow for historical dates not currently available to be specified in markup of documents concerning history. Such dates do not need to be published on the web in machine readable readable formats. How often to do you need to book a flight, or add an event to your calendar that far back in the past? So the web is now used only for business? And we'll be able to predict exactly what uses users will want to make of it? I think not. The original reason for limiting years to a four digit format was that the relevant standard allowed only that. That is no longer the case. At minimum, with signed years now available as an optional part of ISO 8601, datetime should support ±-MM-DD dates, so as to cover historical dates which some users may find of use, though admittedly probably not business users. Adding one or two additional digits would also enable a closer match with the range of time values allowed in the DOM representation, and would need to be added at the same time as the ± is added.
Re: [whatwg] Expanding datetime
There's an historical precedent that argues in favor of expanding the datetime string. Many calendar utilities limit the date domain to the UNIX one. Thus, entering an anniversary for a wedding that occurred prior to 1970 is the kiss-of-death: there is no way to determine just which anniversary is involved (silver anniversary, paper, ceramic...). A small item? Not to the gift card and gift industries. So an apparently trivial, supposedly non-business limitation had a big effect. Whether or not providing a means to specify dates before the Gregorian Reform or before the beginning of the first millennium will have a business effect is difficult to determine. One thing that can be said is that the applications which would be enabled certainly won't exist if the facilities are not present. Currently, the extreme datetime values (as opposed to the strings) can be specified in Javascript. Producing the corresponding datetime strings from such values should be mandatory. That argues in favor of proper round trip handling: the conversion of extreme datetime strings should be available too. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ernest Cline Sent: Thursday, 2008 April 24 13:58 To: Lachlan Hunt Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Expanding datetime -Original Message- From: Lachlan Hunt [EMAIL PROTECTED] Ernest Cline wrote: From a practical viewpoint, being able to specify dates before January 1, 1 BC (Gregorian) would allow for historical dates not currently available to be specified in markup of documents concerning history. Such dates do not need to be published on the web in machine readable readable formats. How often to do you need to book a flight, or add an event to your calendar that far back in the past? So the web is now used only for business? And we'll be able to predict exactly what uses users will want to make of it? I think not. The original reason for limiting years to a four digit format was that the relevant standard allowed only that. That is no longer the case. At minimum, with signed years now available as an optional part of ISO 8601, datetime should support ±-MM-DD dates, so as to cover historical dates which some users may find of use, though admittedly probably not business users. Adding one or two additional digits would also enable a closer match with the range of time values allowed in the DOM representation, and would need to be added at the same time as the ± is added.
Re: [whatwg] Expanding datetime
Ernest Cline wrote: -Original Message- From: Lachlan Hunt [EMAIL PROTECTED] Ernest Cline wrote: From a practical viewpoint, being able to specify dates before January 1, 1 BC (Gregorian) would allow for historical dates not currently available to be specified in markup of documents concerning history. Such dates do not need to be published on the web in machine readable readable formats. How often to do you need to book a flight, or add an event to your calendar that far back in the past? So the web is now used only for business? And we'll be able to predict exactly what uses users will want to make of it? No, I was just trying to emphasise the use cases that some of the datetime features have been included for. I think not. The original reason for limiting years to a four digit format was that the relevant standard allowed only that. That is no longer the case. At minimum, with signed years now available as an optional part of ISO 8601, datetime should support ±-MM-DD dates, so as to cover historical dates which some users may find of use, though admittedly probably not business users. Please describe the authoring use cases that you are trying to solve and explain how and why authors or end users would benefit from having such dates marked up in a machine readable way, and why would it be in the interest of browser vendors to implement this feature? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Expanding datetime
Henri Sivonen: Date form widgets are meant for airline and hotel reservations What about, for instance, adjustable timelines at history websites or virtual skies at astronomic sites?
Re: [whatwg] Expanding datetime
On Fri, 25 Apr 2008 07:54:37 +0800, Christoph Päper [EMAIL PROTECTED] wrote: Henri Sivonen: Date form widgets are meant for airline and hotel reservations What about, for instance, adjustable timelines at history websites or virtual skies at astronomic sites? Hmmm. The ability to show continental drift using a timeline probably doesn't need a datetime (century is usually pretty fine-grained). But virtual skies are pretty important to historical as well as future stuff. There must be about half a billion people who would like to be able to recreate the night skies around Bethlehem in a period between say -0010-01-01 and 0004-01-01 to see if there is something interesting happening. There are various ecological things that are well-suited to timelines stretching back 2009 years. Urban planning and economics is another area that may use the ability to look at things 2009 years ago. Historical weather modelling is another - there are points in history where the date is actually relevant, in particular the ability to match up phenomena known to have occurred in order to synchronise dates calculated according to different and not entirely-known methods. As an historian, these seem useful things to be able to do. It would seem to me as a browser maker that this doesn't actually complicate life a whole lot (I may be wrong - I haven't thought hard about the implications yet). As a standards guy, I do not see that being able to do this would introduce any particular complications (beyond a few more test cases). I am inclined to think that the use cases justify the cost, at least enough to investigate further. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] Expanding datetime
There are various ecological things that are well-suited to timelines stretching back 2009 years. Genealogy would seem to be another relatively popular use. -- Charles
[whatwg] Expanding datetime
The range of valid datetime strings is a subset of those specified by ISO 8601. Most of the unused formats have been rejected on the grounds of simplicity of parsing, but a format (I think added in ISO 8601:2004, but it may have been earlier) offers a gain in utility that would not be unduly complicated to implement. Datetime is current limited to years in the range of - . Additional digits could be added to the year and still keep the string a valid ISO 8601 string, provided that the number to be added is agreed to and the added digits are always preceded by either a + or -. For example, if one digit is added, then the day before -01-01 could be represented as -1-12-31. From a practical viewpoint, being able to specify dates before January 1, 1 BC (Gregorian) would allow for historical dates not currently available to be specified in markup of documents concerning history. The Y10K problem can also be pushed back by this, but is of only theoretical impo rtance. That said, a decision would be need to be made as to the number of extra digits. ISO 8601 requires an implementation to specify a fixed number of added digits, because otherwise a value such as +00019 would be ambiguous in a implementation that used the full set of ISO 8601 formats. (+00019 could be the year 19 AD or the 19th century AD, depending upon whether one or three digits was added.) That datetime doesn't use lone centuries doesn't matter. Since the DOM assumes that time values will be stored as per ECMAScript type floats, for me the question of how many digits to add boils down to a simple one. Is it preferable for all dates specified by datetime strings to be valid values to store in a Date object in ECMAScript, or would it be better for all values in a Date object to have a valid datetime string? Currently the specification for datetime, because of its limit to four digits years goes along with the former not the latter. We could add one digit and increase the range of allowable years from 100,001 BC to 99,999 AD and stay with in the range of a Date object. Adding two digits, would allow all Date objects to have a representation as a datetime string. (Adding zero digits and just adding the ability to add a sign is also an option, but would in my opinion be lesser than either of the other two options.)
