RE: Where are we?

Just a small point: In ISO-8601, no time zone at all actually means local
time, which may sometimes be useful to express.  The shorthand for UTC is
the character "Z" in that standard.  So Dean's compacted example of
"tv:east.pbs.org#19991011T18/19991011T1830" is actually 18:00 to 18:30 local
time, while "tv:east.pbs.org#19991011T18Z/19991011T1830Z" would be 18:00 to
18:30 UTC.

I agree that it's best to use time zones, but I think it's a mistake to
prohibit local times altogether.  We actually made this mistake in the
EIA-746 standard in the US and left ourselves with no way to representing
local time, and we regret it now.  I think one character for UTC is a small
price to pay to keep this option open.

	Dan


--------------------------------------------------- 
Dan Zigmond 
Senior Manager, Broadcast Applications 
WebTV Networks, Inc. 
djz@corp.webtv.net 
--------------------------------------------------- 



-----Original Message-----
From: dean blackketter [mailto:dean@corp.webtv.net]
Sent: Tuesday, October 12, 1999 8:11 AM
To: Harald Tveit Alvestrand; Dan Zigmond; www-tv@w3c.org
Subject: RE: Where are we?


At 10:29 AM 10/11/99 -0700, Dan Zigmond wrote:
>One of my colleagues, Dean Blackketter, has been working on a system for
>describing time periods using the URI fragment syntax.  This seems like a
>fairly natural extension of the notion of fragment into the time domain,
>since in a sense what you're asking for is a way to specify that fragment
of
>a television stream that contains the material broadcasted at a particular
>time.
>
>I'll let Dean post a more complete specification, but the basic syntax uses
>ISO-8601 time formats and looks something like this:

I'll post the complete description in a day or so. I'm currently swamped 
with some emergency bug-fixing, but I had a couple of notes...

>         tv:pbs.org#1999-10-11T13-00-00/1999-10-11T13-30-00
>
>which represents whatever is on PBS between 1PM and 1:30 today.  I've made
>this unnecessarily long just as an example; in 8601 you can drop the
>trailing zeros, and the date itself is optional.  I think 8601 is a pretty
>complete and flexible representation of time, so leveraging it makes the
>problem a lot simpler than having to make something up.
>
>As has been pointed out, this is a fundamentally different problem than
URIs
>for specific programs on television, which should be independent of both
>network and time.

At 10:22 AM 10/12/99 +0200, Harald Tveit Alvestrand wrote:
>Seems logical.
>two things to note:
>
>- dropping the date is unwise in the extreme unless you want the syntax to
>   mean "every day" - which is an extension I would very much like to
avoid.
>   see below.

Yes.  Actually, ISO-8601 doesn't have a date-dropped form, but our 
implementation does as an extension.  A dropped date indicates the next 
matching time in the next 24 hours.  It's a compact form that's useful for 
referring to a program that's on in same evening.

>- On the principle of "all URLs escape the context for which they were
>   created", I would VERY much like to ask for the mandatory inclusion of
>   timezone. You never know who is going to try to watch this, via what 
> medium.
>
>So your example (also including a feed identifier) would become
>
>tv:east.pbs.org#1999-10-11T13-00-00+0500/1999-10-11T13-30-00+0500
>
>and be unambiguous whether it was looked up in Texas or California.

That's right.  But we also allow for the dropping of the zone indicator 
("+0500" in your example) to be equivalent to "+0000" to mean that the time 
is UTC.  So your example could be compacted (by removing trailing zeros, 
optional hyphens and folding the zone into the time in UTC) as:

tv:east.pbs.org#19991011T18/19991011T1830

And still be unambiguous.

I'll post a complete description of the syntax we are using as soon as I
can.

Thanks,

dean

Received on Tuesday, 12 October 1999 17:08:02 UTC