On Wed, 15 Jun 2011, Lachlan Hunt wrote:
On 2011-06-15 07:55, Ian Hickson wrote:
On Mon, 28 Mar 2011, Lachlan Hunt wrote:
This should also only allow up to 3 digits representing
milliseconds. If there are 4 or more digits (microseconds or
beyond), the spec should state that the
On Wed, 11 Jan 2012, Ian Hickson wrote:
On Wed, 15 Jun 2011, Lachlan Hunt wrote:
On 2011-06-15 07:55, Ian Hickson wrote:
On Mon, 28 Mar 2011, Lachlan Hunt wrote:
This should also only allow up to 3 digits representing
milliseconds. If there are 4 or more digits (microseconds or
On 2011-06-15 07:55, Ian Hickson wrote:
On Mon, 28 Mar 2011, Lachlan Hunt wrote:
This should also only allow up to 3 digits representing milliseconds. If
there are 4 or more digits (microseconds or beyond), the spec should
state that the remaining digits should be truncated.
Why?
Because
On Mon, 28 Mar 2011, Lachlan Hunt wrote:
The algorithm to parse a time component contains a bug.
When parsing the seconds, the spec states:
Collect a sequence of characters that are either characters in the
range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9) or U+002E FULL
Hi,
The algorithm to parse a time component contains a bug.
When parsing the seconds, the spec states:
Collect a sequence of characters that are either characters in the
range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9) or U+002E FULL
STOP characters. If the collected sequence has
On Tue, 31 Aug 2010, Martin Janecke wrote:
(1) There's the example of relative date phrases that refer to an absolute
date. For example:
time datetime='2009'Last year/time's temperature was above average.
What's the use case here? What problem is this solving that isn't solved
by just
Am 31.08.2010 22:21 schrieb Martin Janecke:
Am 31.08.10 21:40, schrieb Aryeh Gregor:
On Tue, Aug 31, 2010 at 5:25 AM, Martin Janeckewhatwg@kaor.in
wrote:
Besides,time2010/time in a British news article would allow
users e.g.
in Japan to have these dates displayed as 平22年. That's clearly
Aryeh Gregor writes:
On Tue, Aug 31, 2010 at 3:53 PM, Ashley Sheridan
a...@ashleysheridan.co.uk wrote:
I think localisation does have a valid use though. Consider a page
written in English with the date 01/12/2010. Is that date the 1st
December, or the 12th January? The only clue might
On Tue, Aug 31, 2010 at 4:19 PM, Ashley Sheridan
a...@ashleysheridan.co.uk wrote:
Because as I mentioned, content authors tend to be quite lazy, and leave
default settings on. So lots of English people end up using American
spelling, and American date formatting, because that's what their
On Tue, Aug 31, 2010 at 5:25 AM, Martin Janecke whatwg@kaor.in wrote:
Besides, time2010/time in a British news article would allow users e.g.
in Japan to have these dates displayed as 平22年. That's clearly an advantage
over the number 2010 alone.
I would say the opposite. If they can read
On Tue, 2010-08-31 at 15:40 -0400, Aryeh Gregor wrote:
On Tue, Aug 31, 2010 at 5:25 AM, Martin Janecke whatwg@kaor.in wrote:
Besides, time2010/time in a British news article would allow users e.g.
in Japan to have these dates displayed as 平22年. That's clearly an advantage
over the
On Tue, Aug 31, 2010 at 3:53 PM, Ashley Sheridan
a...@ashleysheridan.co.uk wrote:
I think localisation does have a valid use though. Consider a page written in
English with the date 01/12/2010. Is that date the 1st December, or the 12th
January? The only clue might be the spelling of certain
Am 31.08.10 21:40, schrieb Aryeh Gregor:
On Tue, Aug 31, 2010 at 5:25 AM, Martin Janeckewhatwg@kaor.in wrote:
Besides,time2010/time in a British news article would allow users e.g.
in Japan to have these dates displayed as 平22年. That's clearly an advantage
over the number 2010 alone.
I
On Tue, 2010-08-31 at 16:09 -0400, Aryeh Gregor wrote:
On Tue, Aug 31, 2010 at 3:53 PM, Ashley Sheridan
a...@ashleysheridan.co.uk wrote:
I think localisation does have a valid use though. Consider a page written
in English with the date 01/12/2010. Is that date the 1st December, or the
On Sat, 7 Aug 2010, Tantek �~Gelik wrote:
the new time element is very useful for absolute dates and times, but
omits several useful granularity levels, in particular for dates.
The following additional date granularities would be useful, and are
fairly straightforward to incorporate into
Hi there,
I’d like to contribute to the discussion on the time element with
some use cases
On Thu, Mar 19, 2009 at 10:35 AM, Ian Hickson i...@hixie.ch wrote:
The primary use cases for time are:
* The ability to encode 80% of dates and times in a machine-readable way
so that the user can
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#parse-a-month-component
Is there a use case for machine-readable dates after ? I'm sure HTML5
will have been obsoleted before it's meaningful to express accurate times
that far in the future. As
Leif Halvard Silli wrote:
Mikko Rantalainen 2009-03-13 11.33:
Andy Mabbett wrote:
In message cc3986d1-6ddc-4007-8bba-42a5d4e39...@eatyourgreens.org.uk,
Jim O'Donnell j...@eatyourgreens.org.uk writes
And time is also touted as an accessibilty feature. And this
Proleptic Gregorian calendar
Smylers wrote:
Robert J Burns writes:
Right now we have a draft that: 2) allows without attaching
sufficient meaning to it
I don't think that's the case; the algorithm for parsing a year requires
a number greater than zero:
Tom Duhamel wrote:
that the use of non Gregorian is to be supported, I would go with the later
solution (allow non Gregorian as the content only, and have the datetime
attribute always defined as a Gregorian date), since that would not put much
How about specifying that the content of time
The most the specification can say about dates without a machine-readable
value attribute is that the user agent should do its best to figure out what
the content means given the language the document is in, perhaps with
precedence given to Gregorian calendar in case of doubt. The exact rules
for
At 19:01 -0500 14/03/09, Robert J Burns wrote:
The problem isn't that negative integers are not well-defined and
understood well. The problem is understanding how an ISO 8601
representation - such as these examples include - maps to an
author's or user's understanding of the year 2 BC (or is
It seems that pretty much everyone agrees on this:
- Allow the use of an alternate calendar, but only Gregorian is required to
be understood by user agents
- We only require the user agent to display dates; they are free to do more
if they like (conversion, ...) but are not required to.
- Calendar
On 16 Mar 2009, at 20:10, Tom Duhamel wrote:
It seems that pretty much everyone agrees on this:
- Allow the use of an alternate calendar, but only Gregorian is
required to be understood by user agents
- We only require the user agent to display dates; they are free to
do more if they like
Tom Duhamel writes:
It seems that pretty much everyone agrees on this:
Hi Tom. I'd like you to clarify an aspect of your proposal:
time2009-03-16/time
Printing directly on the page, no tool tip: March 16, 2009
Because the author wrote a date in ISO 8601 format, a browser should
rewrite it
Assuming that Gregorian dates are displayed in a tool tip, what happens when
the user hovers over a time element that has both @datetime and @title
specified?
Chris
On Mon, Mar 16, 2009 at 5:03 PM, Smylers smyl...@stripey.com wrote:
Hi Tom. I'd like you to clarify an aspect of your proposal:
Please don't see this as a proposal, but rather as a compilation of the
things people seem to have agreed on so far. My intention was to compile in
one post what
On Mon, Mar 16, 2009 at 5:05 PM, Robert J Burns r...@robburns.com wrote:
Hi Tom,
I think those examples and suggestions all look good. I have one correction
and one other example.
First the correction
time calendar=Mayan datetime=12-11-10-09-08A date/time is printed
on the statue
[I left Robert's replies in, even those I didn't have anything to reply to,
because Robert originally sent the message only to me (off-list).]
On Sun, Mar 15, 2009 at 4:36 PM, Robert J Burns r...@robburns.com wrote:
- Allow only extended format: 2009-03-14 (rather than 20090314) which will
In message 20090314083450.ga30...@stripey.com, Smylers
smyl...@stripey.com writes
This thread appears to be proving that dates are very complicated and
that to get them right for the general case involves lots of subtleties,
All true.
which would be a reason for punting -- only doing the
On 13 Mar 2009, at 16:19, David Singer wrote:
Can we drop this topic? Apart from suggesting
a) that the fully delimited date format be required (extended format);
b) that year and before be allowed;
c) that parsing the body text as 8601 may be dangerous if it's
notated the same way but
On 13 Mar 2009, at 10:33, Mikko Rantalainen wrote:
This is already a solved problem in the Text Encoding Intiative
(TEI).
The value of a date/time is encoded in the Gregorian calendar,
using
ISO8601. The calendar attribute is used to indicate the calendar of
the original, written date
Andy Mabbett writes:
In message 20090314083450.ga30...@stripey.com, Smylers
smyl...@stripey.com writes
This thread appears to be proving that dates are very complicated
and that to get them right for the general case involves lots of
subtleties,
All true.
which would be a reason
On Sat, Mar 14, 2009 at 8:23 AM, Smylers smyl...@stripey.com wrote:
only doing the simplest possible
thing for now, acknowledging that that doesn't meet all desirable
scenarios, and leaving everything else for HTML 6.
I'm proposing that we don't hold up that standard while trying to solve
On Sat, Mar 14, 2009 at 9:36 PM, Smylers smyl...@stripey.com wrote:
Tom Duhamel writes:
- Allow only extended format: 2009-03-14 (rather than 20090314) which
will help with simplification and future extensions
Note that the draft already requires hyphens, so this wouldn't be a
change:
Robert J Burns wrote:
...
Let us keep in mind that the HTML5 draft does not reference ISO 8601. It
also already reaches way beyond ISO 8601 and claims to handle dates all
the way back to -01-01 whereas ISO 8601 only handles dates between
1582 and . So HTML5 already takes on the task
An author need not be the first author. An editor charged with maintaining
a site where Julian date markup is used would have to learn Julian date
markup. In this way, whenever we include a feature that we consider
optional, we ultimately make the editors, if not the primary authors, learn
about
At 17:02 +0100 13/03/09, Leif Halvard Silli wrote:
I struggle to understand why it is better to ask *authors* to use
One True Calendar instead of e.g having a scheme attribute through
which the author can specify the date/time format.
You might want to read
At 19:26 -0500 13/03/09, Robert J Burns wrote:
The chief accomplishments of ISO 8601 is the ability to represent
dates in a uniform manner and in defining the Gregorian calendar
from 1582 to in an unambiguous way. Beyond those dates it
leaves things imprecise and ambiguous.
You keep
Hi Robert
On 12 Mar 2009, at 02:53, Robert J Burns wrote:
Since you keep repeating the following example (by copy and paste?)
I will mention that you have the year wrong in one place or the
other (1731 and 1732). Dates only diverge by years between Julian
and Gregorian many millions of
David Singer wrote:
At 3:22 +0100 10/03/09, Charles McCathieNevile wrote:
The other issue is the one of precision - while you can name a single
year, which will deal with a lot of use cases there are a lot left out
because the precision required is a period. Ranges are included in
8601, and
On Thu, 12 Mar 2009 17:05:38 +0530, Lachlan Hunt
lachlan.h...@lachy.id.au wrote:
I think the design principles that are applicable here include Solve
Real Problems [2],
Real problems to be solved:
1) microformats have accessibility problems with abbr; time element
solves that - but if
Bruce Lawson wrote:
On Thu, 12 Mar 2009 17:05:38 +0530, Lachlan Hunt
lachlan.h...@lachy.id.au wrote:
I think the design principles that are applicable here include Solve
Real Problems [2],
Real problems to be solved:
1) microformats have accessibility problems with abbr; time element
David Singer wrote:
So far, we've had vague use cases
related to historians and time lines
In what way do you consider those use cases vague, and what would it
take for you to consider them less so?
there's been no clear description of the problems that
need solving
That's clearly an
On 10 Mar 2009, at 17:03, David Singer wrote:
At 3:22 +0100 10/03/09, Charles McCathieNevile wrote:
That format has some serious limitations for heavy metadata users.
In particular for those who are producing information about
historical objects, from British Parliamentary records to
Geoffrey Sneddon wrote:
...
Ultimately, why is the Gregorian calendar good enough for the ISO but
not us? I'm sure plenty of arguments were made to the ISO before ISO8601
was published, yet that still supports only the Gregorian calendar,
having been revised twice since it's original
At 17:53 +0100 12/03/09, Julian Reschke wrote:
Geoffrey Sneddon wrote:
...
Ultimately, why is the Gregorian calendar good enough for the ISO
but not us? I'm sure plenty of arguments were made to the ISO
before ISO8601 was published, yet that still supports only the
Gregorian calendar,
Summary: We should allow at least proleptic Gregorian dates before
0001-01-01 and we should allow ranges. These are low-hanging fruit with
clear use cases. (I don't even get into the question of different
calendars - I will save that for another discussion).
details below.
On Thu, 12 Mar 2009
At this point, I think I'm in strong agreement with two points, that
of allowing negative years and of allowing a range.
Allowing negative years is so trivial on the parsing side as to make
it somewhat ridiculous that it's not supported. The use-cases for a
full year-month-day in BC times are
Notation for negative quantities usually starts with a minus (with
exceptions for bookkeeping). It still does even though ASCII unified the
hyphen with the minus.
We cannot perform interval arithmetic on intervals with unknown limits or
compare them. Automated processing tools would not benefit
Am Dienstag, den 10.03.2009, 17:37 -0400 schrieb Aryeh Gregor:
A much saner solution seems to be to say that HTML supports exactly
one type of calendar: in this case, proleptic Gregorian. Authoring
tools can be used to convert from other formats to Gregorian. This is
the approach already
On Thu, Mar 12, 2009 at 1:04 PM, Kristof Zelechovski
giecr...@stegny.2a.pl wrote:
Notation for negative quantities usually starts with a minus (with
exceptions for bookkeeping). It still does even though ASCII unified the
hyphen with the minus.
We cannot perform interval arithmetic on
On Thu, Mar 12, 2009 at 3:48 PM, Robert J Burns r...@robburns.com wrote:
Hi Tab,
On Mar 12, 2009, at 12:51 PM, Tab Atkins Jr. wrote:
At this point, I think I'm in strong agreement with two points, that
of allowing negative years and of allowing a range.
Allowing negative years is so
In message 49b90c20.9040...@lachy.id.au, Lachlan Hunt
lachlan.h...@lachy.id.au writes
* Investigation of how imprecise dates affect the ability to import
such
events into a calendar. e.g. The Sydney Royal Easter show scheduled
for 2009-04, and takes place over a period of a few weeks in the
In message caaf25cf-1fbe-494c-8361-e6811b6c5...@googlemail.com,
Geoffrey Sneddon foolist...@googlemail.com writes
Ultimately, why is the Gregorian calendar good enough for the ISO but
not us? I'm sure plenty of arguments were made to the ISO before
ISO8601 was published, yet that still
In message p06240841c5deeed58...@[17.202.35.52], David Singer
sin...@apple.com writes
At 17:53 +0100 12/03/09, Julian Reschke wrote:
Geoffrey Sneddon wrote:
...
Ultimately, why is the Gregorian calendar good enough for the ISO but
not us? I'm sure plenty of arguments were made to the ISO before
At 16:24 -0500 12/03/09, Robert J Burns wrote:
That was my point: we cannot get a clear answer out of ISO 8601. ISO
8601 only covers dates between 1582 and without supplemental
norms.
No, it says mutual *agreement*, not supplemental norms. ISO
8601:2004 seems perfectly clear that the
Hi Andy
On 12 Mar 2009, at 21:46, Andy Mabbett wrote:
In message caaf25cf-1fbe-494c-8361-e6811b6c5...@googlemail.com,
Geoffrey Sneddon foolist...@googlemail.com writes
Ultimately, why is the Gregorian calendar good enough for the ISO
but not us? I'm sure plenty of arguments were made to
On 11 Mar 2009, at 04:46, Leif Halvard Silli wrote:
This is already a solved problem in the Text Encoding Intiative
(TEI). [ ... ] date calendar=Julian value=1732-02-22Feb. 11,
1731./date [ ... ] We can't change the author's original written
dates, but it would be useful to normalise
At 20:11 -0500 10/03/09, Robert J Burns wrote:
Indeed. That's one of the ways it can be done. IMHO it meets a huge
set of the possible use cases. And it has the sort of simplicity
that tends to be the defining characteristic of the best of HTML5.
(Well, parsing isn't simple and is clearly
On 11 Mar 2009, at 08:54, Robert J Burns wrote:
Authoring tools can be used to convert from other formats to
Gregorian.
And in that regard, it should be very relevant to have a calendar
attribute.
Or reuse the RDFa datatype attribute with new calendar system
keywords.
I'm not
At 3:22 +0100 10/03/09, Charles McCathieNevile wrote:
That format has some serious limitations for heavy metadata users.
In particular for those who are producing information about
historical objects, from British Parliamentary records to histories
of pre-communist Russia or China to museum
Hi David,
On 10 Mar 2009, at 17:03, David Singer wrote:
The trouble is, that opens a large can of worms. Once we step out
of the Gregorian calendar, we'll get questions about various other
calendar systems (e.g. Roman ab urbe condita http://
en.wikipedia.org/wiki/Ab_urbe_condita,
In message cc3986d1-6ddc-4007-8bba-42a5d4e39...@eatyourgreens.org.uk,
Jim O'Donnell j...@eatyourgreens.org.uk writes
This is already a solved problem in the Text Encoding Intiative (TEI).
The value of a date/time is encoded in the Gregorian calendar, using
ISO8601. The calendar attribute is
In message 20090309215532.ga3...@stripey.com, Smylers
smyl...@stripey.com writes
Tom Duhamel writes:
My opinion is that all the following dates are precise:
2009
2009-03
2009-03-09
The later is more precise, but the three are all precise in my
opinion.
Being precise means having a small
This seems to provide a good use case for a couple of RDFa attributes:
time xmlns:d=http://dbpedia.org/resource/;
datatype=d:Mesoamerican_Long_Count_calendar
content=12.19.16.2.18
13 Etz'nab' 1 Kumk'u/time
Adopting RDFa in HTML5 not only gives us a technique for embedding
On Tue, Mar 10, 2009 at 3:48 PM, Andy Mabbett a...@pigsonthewing.org.uk wrote:
How widely - compared to Julian dates - are those published, in the wild?
You might be tending towards 'Reductio ad absurdum'.
There are definitely many non-Julian/Gregorian calendar systems used
in the wild.
On Tue, 10 Mar 2009 18:03:37 +0100, David Singer sin...@apple.com wrote:
At 3:22 +0100 10/03/09, Charles McCathieNevile wrote:
That format has some serious limitations for heavy metadata users. In
particular for those who are producing information about historical
objects, from British
There have been a lot of discussion around the time element lately, and I
followed most of it since I'm pretty interested in this element, and frankly
I believe it will be very useful in the future. However, I too have opinions
around this. I do agree with some argument presented before, and
Tom Duhamel writes:
My opinion is that all the following dates are precise:
2009
2009-03
2009-03-09
The later is more precise, but the three are all precise in my
opinion.
Being precise means having a small granularity. Obviously that's
subjective, but in many cases granularity of a
On Mon, 09 Mar 2009 21:17:01 +0100, Tom Duhamel tom420.duha...@gmail.com
wrote:
Precise Date/Time
My understanding is that the current protocol will only accept this
format for a valid precise date:
2009-03-09
And this format for a valid precise time:
15:10 or 15:10:19
My opinion is
It does seem to me to be a little foolhardy for HTML5 to be defining
its own format for representing dates and times. ISO 8601 is already
widely understood and implemented. Out of the box it is capable of
representing any instant[1] between 1 BC and AD, including
leap seconds and
(I thnk this is a permathread for the moment, so posting it to HTML as
well for reference. Is there an issue raised for this, or whatever the
method /du jour/ for identifying questions to be dealt with is?)
On Tue, 10 Mar 2009 01:36:33 +0100, Toby A Inkster
m...@tobyinkster.co.uk wrote:
I note that the time element has four attributes.
The three attributes of type DOMTimeStamp (the date, time, and timezone
attributes)
seem the most troublesome, for the following reasons.
Since DOMTimeStamp is an unsigned long integer, and 0 ms represents
1970-01-01 00:00 UTC, (the proposed HTML
The part of the spec at
http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.h
tml#date-or-time-string
in the 2.4.4.2 Vaguer moments in time section contains a typographical
error. In this phrase:
If second is not a number in the range 0 ? minute 60, then the string is
On Fri, 23 Mar 2007, Colin Lieberman wrote:
Matthew Raymond wrote:
I support the time element for the opposite reason, in fact. I don't
want to see authors styling the date format. I'd rather see the date
format localized or customized to a user preference. If the author
wants it in
Colin Lieberman wrote:
Matthew Raymond wrote:
I support the time element for the opposite reason, in fact. I
don't want to see authors styling the date format. I'd rather see the
date format localized or customized to a user preference. If the author
wants it in a specific format, they can
Matthew Raymond wrote:
I support the time element for the opposite reason, in fact. I
don't want to see authors styling the date format. I'd rather see the
date format localized or customized to a user preference. If the author
wants it in a specific format, they can use CSS to style the
d.latapie wrote:
pHe was driving his parent´s colorblue/color car./p
Do you see any difference in relevance here? I don´t.
That's because your time example deliberately uses time in a
frivolous manner.
The time example is not mine, it is WHATWG's.
It still sucks! ;)
The question
David Latapie wrote:
Hello,
I have some trouble inderstanding the need for these elements really.
Especially when considering the example:
http://www.whatwg.org/specs/web-apps/current-work/#the-time
pOur first date was time datetime=2006-09-23a saturday/time./p
Out of sorting all the
Hello,
I have some trouble inderstanding the need for these elements really.
Especially when considering the example:
http://www.whatwg.org/specs/web-apps/current-work/#the-time
pOur first date was time datetime=2006-09-23a saturday/time./p
Out of sorting all the events that happened that day,
On Thu, 08 Feb 2007 20:31:05 +0100, David Latapie [EMAIL PROTECTED]
wrote:
Just a little bit more serious
Now that we are going to implement meter, we need the whole of Système
International: kilogram, ampere, Kelvin, mole and candela (is
time a good replacement for second, I don't know)
Have
It's quite clear how conformance checkers have to check the datatime=
attribute and the contents of the element, but what authors have to do is
not made very clear in the document.
As for the APIs. Is there any reason you can't just reuse the ECMAScript
Date object? (Other languages would
83 matches
Mail list logo
