Subject: PaceDateAsbjornUlsberg -1

From: Dare Obasanjo <[email-masked]>
Date: Wed, 11 Aug 2004 09:46:46 -0700 (PDT)

From my perspective as an aggregator developer this
seems like way too many dates and the semantics of
some of them confused me (especially the subtle
difference between atom:b & atom:c). I can't think of
which of the dates my application should depend on. 

PS: Stylistically I have issues with the fact that the
Pace references
http://msdn.microsoft.com/library/en-us/dndotnet/html/datetimecode.asp
which is mainly a guide to all the gotchas surrounding
the DateTime class in the .NET Framework. I'm not sure
how it is generally relevant to developers at large
that aren't using the .NET Framework. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #25
No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot.

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

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 11 Aug 2004 20:44:59 +0200

On Wed, 11 Aug 2004 09:46:46 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> From my perspective as an aggregator developer this seems like
> way too many dates and the semantics of some of them confused
> me (especially the subtle difference between atom:b & atom:c).

atom:b is some sort of «first published» while atom:c is the more vague  
«published». If we agree that «published» will never change for a given  
atom:entry, then atom:b can be dropped.

> I can't think of which of the dates my application should depend
> on.

atom:b is really just there because if we don't reach consensus on that  
the date representing the published date is immutable, I'd still need a  
date that conveyed the semantics of «first published». If we all agree  
that atom:c can be immutable, then atom:b can go.

> PS: Stylistically I have issues with the fact that the Pace
> references [...] which is mainly a guide to all the gotchas
> surrounding the DateTime class in the .NET Framework

That has nothing to do with the rest of the pace other than it's a good  
read.

> I'm not sure how it is generally relevant to developers at
> large that aren't using the .NET Framework.

It has some good notes on why it is useful and often necessary to  
normalize dates to UTC before doing anything with them. My Pace requires  
time zones on all dates by basing them on RFC 3339 and recommends  
UTC-normalization of all dates to make them easier to process. If you  
think this is unecessary, please let me know, and I'll try to rephrase the  
pace.

Since you're -1 on the pace, is there anything else you dislike about it?  
Isn't it good that it requires at least one date to be present, for  
example? What could be improved for you to be +1 on it?

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