Subject: Unsynchronized clocks vs. author calendars

From: Walter Underwood <[email-masked]>
Date: Thu, 15 Jul 2004 10:42:31 -0700

The timestamp discussions are confusing two different things,
and calling them both "subjective" timestamps.

Timestamps from an unknown timezone are not subjective. They are
measurements from a clock with a possibly large synchronization
error to UTC (+/-12 hours). Timestamps from one clock can be
ordered, but they cannot always be ordered against other clocks.
If two timestamps are more than 24 hours apart, they can be ordered.

In the LiveJournal case, unsynchronized timestamps can be used to
order entries from a single blog, but might not work for entries
from different blogs.

Author calendars are quite different. The timestamp can usually
be mapped to a UTC time, but the calendar is different. Some example
calendars are Gregorian, Hebrew, stardate, and Mars Rover Spirit
Mission Sol number (thanks to David Chase for that one).

Timestamps with an author calendar might be objective or subjective.
The date might be synchronized to UTC but expressed in a non-Gregorian
calendar.

Atom readers will not have all possible calendars for converting UTC
back into the preferred calendar. Those dates really must be formatted
by the author or the author's tools.

Atom doesn't have to support all kinds of timestamps, but we shouldn't
confuse them.

Hmm, I bet we could use timestamps of non-LiveJournal entries linked
to LiveJournal blogs to discover the synchronization offsets. Causality
and all that. Probably too much work, though.

NOTE: Please respond only to the list. I'm getting plenty of mail
without two copies of responses.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 15 Jul 2004 11:16:24 -0700 (PDT)

I completely could not make head or tails of your
argument. Are you claiming that that Atom feeds will
have to deal with calendars other than the Gregorian
calendar? Since when? Every discussion I've seen has
assumed ISO 8601 commpliant dates. 

> without two copies of responses.

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.

		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

---

From: Martin Duerst <[email-masked]>
Date: Fri, 16 Jul 2004 08:53:25 +0900

At 10:42 04/07/15 -0700, Walter Underwood wrote:

>error to UTC (+/-12 hours).

It's more like +/- 14 hours.

>Timestamps from one clock can be

That would then be something like 28 or so hours.

Regards,     Martin.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 16 Jul 2004 09:35:38 +0200

On Thu, 15 Jul 2004 11:16:24 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> Are you claiming that that Atom feeds will have to deal with
> calendars other than the Gregorian calendar? Since when?

I don't think that's what he's saying, but either way; supporting a  
non-Gregorian calendar isn't stupid. ISO 8601 does not support any such to  
my knowledge, but it should at least be discussed what usages Atom has  
outside of «the western world», e.g. in the Arabic countries, Asia and so  
on.

After all, people using the Gregorian calendar is a minority, right?[1]

> Every discussion I've seen has assumed ISO 8601 commpliant dates.

Yup. That's been the assumption up to now. Non-Gregorian calendars have  
been discussed in brief on #atom, but no solution and even no  
specifications have been found on other calendars. Someone managed to dig  
out some Persian blogs, though, but we couldn't find out if those had any  
feeds (I speak very poor Persion. None, actually ;).

If Atom is not going to support non-Gregorian calendars, it should be  
clear that it doesn't, imho.

____
[1] I have to say that I don't know enough about the subject to say if the  
Gregorian calendar is more widely used than any other. If it isn't, Atom  
should be clear about not supporting others, and not just move along in  
ignorance.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Martin Duerst <[email-masked]>
Date: Fri, 16 Jul 2004 17:31:11 +0900

At 09:35 04/07/16 +0200, Asbj$B�S(Bn Ulsberg wrote:

>outside of $B%)(Bthe western world$B%5(B, e.g. in the Arabic countries, Asia and so
>on.
>

[the following is just a short summary]
Not exactly. It's quite a serious majority, I would guess.
If you count North and South America, Europe, Russia, China,
and so on, you easily get there.
In some countries, for example Japan and Taiwan, a calendar is
used that works exactly the same for months and days, just the
years are numbered differently. In other places, in particular
Israel, the Arabic World, and Ethiopia, there are traditional
calendars that are not aligned in terms of months and days.
In all these cases, the Gregorian calendar is used side-by-side
with the 'traditional' one, but usage differs for each case.
Usually, the Gregorian calendar is more prevalent in business
and for international stuff, while the traditional calendar
is more prevalent for private and in particular for religious
events. Even in places that are (mostly) aligned with the Gregorian
calendar (e.g. China, Japan), there are things that still run
according to an older, traditional calendar, e.g. the Chinese
New Year or Japanese plannig of wedding ceremonies.

>clear that it doesn't, imho.

I think that:
- Atom should concentrate on markup for machine readable dates
- Machine readable dates should be in ISO 8601 notation, which implies
   the Gregorian calendar
- The spec should make clear that this is a format for exchanging
   date/time information, and does not limit how these are being shown
   to a user, or input by a user.
- People who want to add anything else (such as "on a sunny Sunday
   in July" or so) can always put that into the title/description/
   actual item text/wherever appropriate.

Regards,    Martin.

>Asbj$B�S(Bn Ulsberg         -=|=-        [email-masked]
>$B%)(BHe's a loathsome offensive brute, yet I can't look away$B%5(B

---

From: Dan Brickley <[email-masked]>
Date: Fri, 16 Jul 2004 06:42:25 -0400

* Martin Duerst <[email-masked]> [2004-07-16 17:31+0900]
> 
> At 09:35 04/07/16 +0200, Asbj?Sn Ulsberg wrote:
> 
> >outside of ォthe western worldサ, e.g. in the Arabic countries, Asia and 
> >so
> >on.
> >

I'd agree with all this, but would also like to keep open possibility of 
non-Gregorian dates being allowed in feeds using extension namespaces.

I've already been gently flamed offlist for "political correctness" so perhaps
I should clarify that I see this as one of many motivations for a
principled approach to namespace extension. If a community of Atom
producers and consumers, say in Iran, decide they would like to expose
their favourite date notation as a property of feeds and items, and
eg. write XSLT to consume it... wouldn't that be a good thing? (assuming
they include the standard gregorian dates too). This to me seems
broadly analagous to movie site feeds exposing showtime info, personal banking 
feeds exposing payment time info, and the general
utility of representing other kinds of date/time info associated with
the topic of feed items, and doing so in nice clean XML, rather than
mixed up in the textual payload of "title/description/actual item text".

The RSS0.9x world already suffered from people squeezing structured info
(more dates, topics, etc) into textual/prose fields. I'd prefer Atom to create
a market where producers and consumers of interesting feeds can deploy 
stuff using namespace'd extensions, rather than encourage overloading. 

>   actual item text/wherever appropriate.

...though I'd explicitly note something like:

   "...actual item text / wherever appropriate, which might include 
   the use of extension XML namespaces within the Atom feed."

cheers,

Dan

ps. do XSLTs exist to go to/from gregorian and non-gregorian dates? I
looked around for a convertor for the Persian calendar, with an
Atom2HTML.xsl use case in mind, but didn't find anything. Quite likely
wrong search term...

---

From: Walter Underwood <[email-masked]>
Date: Fri, 16 Jul 2004 09:22:49 -0700

--On Friday, July 16, 2004 9:35 AM +0200 Asbjørn Ulsberg <[email-masked]> wrote:
> On Thu, 15 Jul 2004 11:16:24 -0700 (PDT), Dare Obasanjo <[email-masked]>  wrote:
>
> I don't think that's what he's saying, ...

You think correctly. The main point is to distinguish between
unsynchronized dates (LiveJournal) and author-expressed dates.
The latter can be accurate dates in non-Gregorian calendars or
something else (my biorhythms).

Requiring support for non-Gregorian calendars in every Atom
implementation is nuts. It isn't even possible to make a list
of all calendars, so you can't require it.

I can see some use in an Atom element for author-expressed dates
as a string. I would not expect implementations to parse them
as dates. Maybe it will show up as an extension.

wunder

---

From: Dave Pawson <[email-masked]>
Date: Fri, 16 Jul 2004 20:22:01 +0100

>    actual item text/wherever appropriate.

+1 for simplicity | machine processing.

Question though Martin, *are* there any better i18N date formats
that meet that criteria though? m/c readable, yet also are happy with
non Western use?

regards DaveP