Re: [whatwg] Time Parsing

[Ian Hickson]

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 
> > > > beyond), the spec should state that the remaining digits should be 
> > > > truncated.
> > > 
> > > Why?
> > 
> > Because the Date object can only handle precision to 3 decimal places, 
> > and implementations interpret times like "00:59:59." as 
> > "00:59:59.999" instead of rounding it up to "01:00:00.000"
> 
> Fair enough. Done.

To elaborate, what I did was make it non-conforming, and define how to map 
fractional milliseconds to Date objects. I didn't actually make the 
parsing algorithm itself truncate the value, so theoretically if someone 
has non-conforming content with values with fractional milliseconds that 
is processed by software that isn't based on JS, it could still support 
those values.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Time Parsing

[Ian Hickson]

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 remaining digits should be 
> > > truncated.
> > 
> > Why?
> 
> Because the Date object can only handle precision to 3 decimal places, 
> and implementations interpret times like "00:59:59." as 
> "00:59:59.999" instead of rounding it up to "01:00:00.000"

Fair enough. Done.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Time Parsing

[Lachlan Hunt]

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 the Date object can only handle precision to 3 decimal places, 
and implementations interpret times like "00:59:59." as 
"00:59:59.999" instead of rounding it up to "01:00:00.000"


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [whatwg] Time Parsing

[Ian Hickson]

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
>STOP characters. If the collected sequence has more than one U+002E
>FULL STOP characters, or if the last character in the sequence is a
>U+002E FULL STOP character, then fail. Otherwise, let the collected
>string be second instead of its previous value."
> 
> This is incorrect because it allows the second component to contain more 
> than 2 digits before the decimal point.  i.e. "00:00:012.345" would 
> parsed without error.

Fixed.


> 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?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[whatwg] Time Parsing

[Lachlan Hunt]

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 more than one U+002E
   FULL STOP characters, or if the last character in the sequence is a
   U+002E FULL STOP character, then fail. Otherwise, let the collected
   string be second instead of its previous value."

This is incorrect because it allows the second component to contain more 
than 2 digits before the decimal point.  i.e. "00:00:012.345" would 
parsed without error.


The algorithm should instead state to look for 2 digits representing the 
seconds, then check if there's a decimal point, and then check for the 
fractional part of the second.


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.


e.g. "00:00:00."

Technically, that would be 999,900µs, but it needs to be rounded down to 
999ms, not rounded up to 1s.


http://whatwg.org/C#parse-a-time-component

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

[whatwg] time element use cases for less specific datetime values

[Oli Studholme]

Hi there,

I’d like to contribute to the discussion on the  element with
some use cases

On Thu, Mar 19, 2009 at 10:35 AM, Ian Hickson  wrote:

> The primary use cases for  are:
>
>  * The ability to encode 80% of dates and times in a machine-readable way
>   so that the user can make use of them in an automated fashion, in
>   particular for adding dates to a calendar.
>
>  * The ability to restyle dates that contain a "day" component so that
>   they follow user conventions (2000-12-31 vs 31-12-2000 vs 12-31-2000).
>
>  * The ability to encode the output of  and    type=time> in an unambiguous fashion, for styling.
>
> None of these require that  be able to express years or year-month
> pairs; what are the use cases that we should address that need  to
> support these formats?

#1 Adding month or year (imprecise) dates to a calendar
I’m involved in organising events, and as part of this we make plans
for events with approximate times. Currently we use a shared calendar
plus have a list of events and approximate dates on a private website.
Rather than add a list of events to a web page plus add event data to
both a calendar, I’d like to list the events on a web page using
 and hCalendar or a microdata vocabulary, then add these events
to a calendar via a conversion tool. A workaround would be to use full
dates, but that gives a false indication of accuracy.

#2 Restyling dates
As others have already mentioned, in Japan it’s common to display
dates as 20-8-2010, 2010-8-20 and 2010年8月20日. In addition there’s this
fun alternative year system that’s still widely used, including in
official documents such as driver’s licenses, based on eras. Currently
it’s the 22nd year of the Heisei era; 平22年8月20日. As in Hixie’s example
of allowing dates to be restyled to follow user conventions, it would
also be very useful to allow this for year and year-month dates, as
even Japanese people have difficulty converting between the two
systems, especially for anything before they were born. Allowing year
and year-month @datetime values would allow a browser to offer
localisation of date display including conversion between these two
date formats. For example:
   昭9年
could be automatically restyled to
   1935
(that’s the ninth year of the Shōwa era btw ;)

Japanese credit cards frequently list only two digits for expiry year
(eg “10/15”), and some Japanese e-commerce sites use a 2-digit input
for year. Confusingly (well initially for me) these are always the
abbreviated 4-digit year not the era year. Having this information
semantically notated would make it more accessible.

#3 Encoding  unambiguously
If this is a use case, it would be nice to be able to encode all the
datetime-related states of the  element. It’s not currently
possible to use  for month and week input states. It would also
be nice to have a year state for , as it has more use cases
than week, and it would allow combining with the month state for e.g.
credit card info.

Finally, I’m not sure how much of a use-case this makes but I’d like
to use  with microformats and microdata. Not allowing more time
formats (year, year-month, month-day…) restricts the use of  to
vocabularies with year-month-day specific dates.

If these primary use cases have changed please let me know. Hopefully
some of these use cases will be relevant for allowing at least year
and year-month formats for @datetime, as per ISO 8601.

Thanks for your time

peace - oli studholme

[whatwg] Time element, atribute, kind of second

[Gerard Ashton]

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 5 epoch) many events about living
people
cannot be described. While the datetime string is allowed to have year
values
such as 0057, such a value cannot be represented by the date attribute.

Furthermore, the only words in the specification that would imply a
particular
length for the second (and therefore the millisecond) are UTC or Coordinated
Universal Time. Since 1972 UTC has counted in the second of the
International
System of Units, that is, the second of atomic clocks. The actual mean solar
second is slightly longer. From the time of the proposed HTML 5 epoch until
January 1, 2009, atomic time and UTC diverge by 29.7683 seconds. This
accounts
for the leap second that occurs at the end of 2008. The next leap second
after that will cause the difference between HTML 5 time and UTC to be
more than 30 seconds, which means that if rounded to the nearest minute,
the minute value will differ by 1.

This means that the simple process of converting adding the date, time, and
timezone
attributes and converting to a character string representation of the time
(rounded
to the nearest minute) can result in a different minute value relative to
what what a
clock on the wall would show.

The choice of epoch matches the epoch for Unix, but otherwise seems
inconvenient.
The problem of the date attribute failing for some information about living
people
would suggest choosing an epoch before an living person was born, such as
the
adoption of the Gregorian Calendar (1582-10-15). If a date near 1970 really
is
seen as a desirable date, 1973-01-01 00:00 UTC suggests itself, because the
use
of leap seconds began 1973-01-01 00:00 UTC, so any algorithm that needed to
account for the difference between atomic time and UTC would only have to
deal
with integer differences (even if the algorithm needs to work with values
slightly before the epoch).

Considering the inability to represent leap seconds in the time element,
it appears to me the only way to write a specification that does not
contradict
itself is to say that the epoch is 1973-01-01 00:00 UT1, not UTC, and that
the
times represented are UT1 times, not UTC. Thus the unit of measure for the
attributes
would be seconds of mean solar time as measured by UT1, not seconds as kept
by atomic
clocks. Since UT1 does not observe leap seconds,
the limitation of the time element will not cause outright errors and
contradictions.
The absolute value of the difference between UTC and UT1, which is always
less than
0.9 second, seems unlikely to cause trouble for the types of applications
envisioned
for this element.

For further information on the difference between UTC and atomic time (TAI)
see http://maia.usno.navy.mil/ser7/tai-utc.dat

Gerry

[whatwg] Time element, typographical error, and UTC

[Gerard Ashton]

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
invalid, abort these steps. "

the word "minute" should be replaced by "second".

Also, it is quite confusing to have times constantly being refered to as UTC
times, and yet find the following phrase in "2.4.4.1 Specific moments in
time":

"If second is not a number in the range 0 ? second < 60, then fail. (The
value
 60 and 61 are not allowed: leap seconds cannot be represented by datetime
values.) "

Where the time element is described, at
http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-seman
tics.html#the-time-element
the description of the second used is unclear. I infer from the description
that the value
of the time element is the number of UT milliseconds since 1970-01-01 00:00
UTC.
The distinction being that UTC only applies to the initial epoch, 1970-01-01
00:00 UTC.
After the epoch, time is counted in universal time (UT), with no leap
seconds allowed
(that is, a seconds value of 60.500 violates the spec).

Am I on the right track? Should the spec spell this out, or provide a
hyperlink
to a location where it is spelled out?

Gerry

Re: [whatwg] Time and Date (was: Joe Clark's Criticisms of the WHATWG and HTML 5)

[Ian Hickson]

On Fri, 23 Mar 2007, Colin Lieberman wrote:
> Matthew Raymond wrote:
> >
> > I support the  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 element 
> > in such a way as to show its contents:
> > 
> > HTML:
> > | (*)???;YY;D???(*)
> > 
> > CSS (using css3-content):
> > | time { content: contents; }
> 
> I agree to a point. Time and date should be machine readable in markup, 
> but I don't know if UAs should *default* to user preference over-riding 
> the author's chosen format.
> 
> My argument here is cultural or sociological - If, in 10 years, kids 
> grew up only ever seeing dates presented in one format, they wouldn't 
> learn about how dates work elsewhere. This seems like a small thing, but 
> I think the flavor of dealing with varieties of date formats is just one 
> way that we get to participate in a really cool, big world full of lots 
> of different people.

I think it is highly unlikely that  would be so successful as to 
hide all other date formats from users. Would we only be so lucky!

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] time and meter elements

[Ian Hickson]

On Thu, 8 Feb 2007, David Latapie wrote:
> 
> I have some trouble inderstanding the need for these elements really. 
> Especially when considering the example:
> 
> 
> Our first date was a saturday.
> Out of sorting all the events that happened that day, it really seems 
> weird to me.

Yeah, the example isn't compelling. But there has been a lot of demand for 
a  element, most notoriously from the microformats community who are 
current abusing  in lieu of having .


On Tue, 13 Feb 2007, Matthew Raymond wrote:
>
> A  element may have some uses, such as providing a hook for adding 
> people to your contact list:
> 
> | 
> |   John Hopkins
> |   Phone: (359) 555-1701
> | 

Notwithstanding what I consider misuse of  in that example, I would 
encourage people to use hCard to mark up a name instead of us introducing 
an element for the purpose.


> One rationale is localization. The browser can take the time given by 
> the |datetime| attribute and convert it into a localized time. For 
> instance, what does this mean?...
> 
> | We're changing the day of the meeting to 08-03-07.
> 
> Is the date August 3rd, 2007, March 8th, 2007 or March 7th, 2008? 
> Now, look at this:
> 
> | 
> |   We're changing the day of the Inkwells meeting to
> |   08-03-07.
> | 
> 
> The user agent can replace the contents of  with the localized 
> value of |datetime|, with the added plus of having a hook for styling.

Indeed.


On Wed, 14 Feb 2007, Matthew Raymond wrote:
> > 
> > I see where you are going. So, a  element would make sense 
> > (contact management) and maybe also a  element and location, 
> > no?
> 
> Yes, although I'm not sure a microformat wouldn't be just as good. The 
> difference with the  element is that it can contain the minimal 
> amount of information for an event in a calendar:
> 
> | fallback
> 
> That plus the ability to localize times and dates, in my opinion, give 
> the element critical mass.

Right. There are ways of including names without abusing semantics today 
(, for one), but there really was no way to unambigiously include a 
date or time before .

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Time and Date

[Matthew Raymond]

Colin Lieberman wrote:
> Matthew Raymond wrote:
>>I support the  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 element in
>> such a way as to show its contents:
>>
>> HTML:
>> | (*)???;YY;D???(*)
>>
>> CSS (using css3-content):
>> | time { content: contents; }
> 
> I agree to a point. Time and date should be machine readable in markup, 
> but I don't know if UAs should *default* to user preference over-riding 
> the author's chosen format.

   The user agents can do whatever they want. If the user wants to turn
off localization and use the format provided by the author, there's
nothing preventing user agent vendors from providing that functionality.
Another possibility is that there could be a tooltip that pops up with
the localized format when you hover the element. The spec should be
flexible enough to allow user agent vendors to decide what's best for
their users.

> My argument here is cultural or sociological - If, in 10 years, kids 
> grew up only ever seeing dates presented in one format, they wouldn't 
> learn about how dates work elsewhere. This seems like a small thing, but 
> I think the flavor of dealing with varieties of date formats is just one 
> way that we get to participate in a really cool, big world full of lots 
> of different people.

   With all due respect, there are too many date formats just in the
United States alone. While you may have some nostalgia for various date
formats, having different formats make it harder to read the dates,
especially when the year is abbreviated (in which case you may not even
be able to read the date at all).

> Yes - dates should be standardized for machines. This allows AT to help 
> folks with (for example) learning disabilities.

   Correct, and in addition, you can use it for things like scheduling
events or opening your calendar to see if you're doing anything at that
date and time. Also, in editors, it would allow you to very quickly
change the fallback date format.

> No - people should not only be served one flavor of date format unless 
> they need it.

   Right now they are being served one flavor: the author's. If the user
wants to see a localized date for their convenience, one can hardly
argue that they should be forced to view the original format provided by
the author. If they don't like localization, the user agent vendors can
always allow the feature to be turned off.

   Keep in mind that the date and time inputs will be localized as well,
so it only makes sense that localization for  should be the
default. Otherwise, the page could have date information in a different
format from that of the date controls.

[whatwg] Time and Date (was: Joe Clark's Criticisms of the WHATWG and HTML 5)

[Colin Lieberman]

Matthew Raymond wrote:

   I support the  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 element in
such a way as to show its contents:

HTML:
| (*)???;YY;D???(*)

CSS (using css3-content):
| time { content: contents; }


  


I agree to a point. Time and date should be machine readable in markup, 
but I don't know if UAs should *default* to user preference over-riding 
the author's chosen format.


My argument here is cultural or sociological - If, in 10 years, kids 
grew up only ever seeing dates presented in one format, they wouldn't 
learn about how dates work elsewhere. This seems like a small thing, but 
I think the flavor of dealing with varieties of date formats is just one 
way that we get to participate in a really cool, big world full of lots 
of different people.


Yes - dates should be standardized for machines. This allows AT to help 
folks with (for example) learning disabilities.
No - people should not only be served one flavor of date format unless 
they need it.


Just my two cents,
Colin Lieberman

Re: [whatwg] time and meter elements

[Matthew Raymond]

d.latapie wrote:
>>> He was driving his parent´s blue car.
>>>
>>> Do you see any difference in relevance here? I don´t.
>>
>>That's because your  example deliberately uses  in a
>> frivolous manner.
> 
> The  example is not mine, it is WHATWG's.

   It still sucks! ;)

> The question is: where to stop? Most substantives have a semantic 
> meaning, shall we tag everything?

   There has to be a significant use case. Data that integrates with
standard business applications such as calendar software is a good example.

> I see where you are going. So, a  element would make sense 
> (contact management) and maybe also a  element and location, 
> no?

   Yes, although I'm not sure a microformat wouldn't be just as good.
The difference with the  element is that it can contain the
minimal amount of information for an event in a calendar:

| fallback

   That plus the ability to localize times and dates, in my opinion,
give the element critical mass.

> Our meeting with Texaco in Houston on the 3rd of 
> July is of utmost importance.

   An address would be more useful than GPS coordinates. Too bad there's
already an  element. The  element turns out to be very
similar to  from HTML+.

Re: [whatwg] time and meter elements

[Matthew Raymond]

David Latapie wrote:
> Hello,
> 
> I have some trouble inderstanding the need for these elements really. 
> Especially when considering the example:
> 
> 
> Our first date was a saturday.
> Out of sorting all the events that happened that day, it really seems 
> weird to me.
> 
> (irony below)
> I have an idea for another element: 
> 
> He was driving his parent’s blue car.
> Do you see any difference in relevance here? I don’t.

   That's because your  example deliberately uses  in a
frivolous manner.

> By the way, what about:
[...]
> or
> He[]was driving his 
> parent’s blue car.

   A  element may have some uses, such as providing a hook for
adding people to your contact list:

| 
|   John Hopkins
|   Phone: (359) 555-1701
| 

   Use case may be a little weak, though, I'll grant you that.

> (is  a good replacement for , I don't know)

   The  element provides a value that represents a specific point
in time, not a measurement of how much time has past.

> Err...
> 
> OK, now, seriously: what is the rationale behind this?

   One rationale is localization. The browser can take the time given by
the |datetime| attribute and convert it into a localized time. For
instance, what does this mean?...

| We're changing the day of the meeting to 08-03-07.

   Is the date August 3rd, 2007, March 8th, 2007 or March 7th, 2008?
Now, look at this:

| 
|   We're changing the day of the Inkwells meeting to
|   08-03-07.
| 

   The user agent can replace the contents of  with the localized
value of |datetime|, with the added plus of having a hook for styling.

   Another purpose would be for event scheduling. User agents could
provide UI that would allow you to create an event in your calendar
using the contents of the  element:

| 08-03-07

   Are these not sufficient use cases?

Re: [whatwg] time and meter elements

[Anne van Kesteren]

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: , , ,  and  (is
 a good replacement for , I don't know)


Have you read what  is about? Because it seems to me like you  
didn't...



--
Anne van Kesteren

[whatwg] time and meter elements

[David Latapie]

Hello,

I have some trouble inderstanding the need for these elements really. 
Especially when considering the example:


Our first date was a saturday.
Out of sorting all the events that happened that day, it really seems 
weird to me.

(irony below)
I have an idea for another element: 

He was driving his parent’s blue car.
Do you see any difference in relevance here? I don’t.

By the way, what about:
He was driving his parent’s blue 
car.

or
He was driving> his 
parent’s blue car.



Just a little bit more serious
Now that we are going to implement meter, we need the whole of Système 
International: , , ,  and  (is 
 a good replacement for , I don't know)


Err...



OK, now, seriously: what is the rationale behind this?



Perfection is achieved, not when there is nothing more to add, but when 
there is nothing left to take away. -- Antoine de Saint-Exupéry
-- 
 U+0F00
http://blog.empyree.org/en (English)
http://blog.empyree.org/fr (Français)
http://blog.empyree.org/sl (Slovensko)