RE: skipHours and skipDays ambiguous vs. non-optimal
> Message: 2No, I am not implying. I am stating quite unequivocally that I
> Date: Wed, 08 Feb 2006 21:19:19 -0000
> From: "ecomputerd" <ecomputerd@...>
> Subject: skipHours and skipDays ambiguous vs. non-optimal
> Your statement "good enough for what we are trying to achieve"
> implies that we are trying to fix the spec instead of clarify it.
believe these elements to be dysfunctional so why discuss how
to do a better job of explaining they are broken?
They don't seem to be broken to you though so if you would try
to explain it to me like I was a four year old (as they say in
the movies). Here's as typical a scenario as any and I have to
put this into perspective...
Nobody gives a sh!t what time it is in Greenwich except the
tavern owners in Greenwich. I and my customers want and need
to use time relevant to our personal location and the purpose
our feeds are intended to achieve.
Just today I studied Apple's iTunes specification which states...
<! - valid date and time format - >
<pubDate>Wed, 6 Jul 2005 13:00:00 CST</pubDate>
<pubDate>Wed, 6 Jul 2005 13:00:00 -0600</pubDate>
Noting I modified the actual time zone and offset designators
to coincide with my own locale, if my channel builder formatted
the pubDate string in either format as shown would your FeederReader
parse the *times* correctly and if so could I safely presume
others who parse feeds could/would also do so?
By "parsing the time correctly" I mean having sufficient information
available within the pubDate element itself to style the results
such that the page could display "This feed was first published
on Wednesday, July 6th 2005 at 1:00 PM CST?"
Sorry to switch elements on you :-) but this example has a method
to its madness.
<%= Clinton Gallagher