Re: --from/--until discussion (New Developer???)

On Thursday 24 October 2002 03:38 pm, Ed Avis wrote:
> If you do that then any code-simplicity advantage disappears, because
> one 'day' might map to one, two or possibly even three time periods
> from the site.  The main UK grabber for example has day boundaries at
> roughly 06:00, although it varies a little from one day to the next.

So for the main UK grabber we'd need to do some conversions from either
set of options due to the fact that roughly 24:00-06:00 is potentailly part 
of yesterday?

> >>Specifying a pair of times is unambiguous; specifying a day and a
> >>number of days is fraught with complications.  Unfortunately.
> >
> >Like you said before; the code to go from dates in the future or
> >past to day offsets is relatively simple (with the proper
> >Date/Calendar class or library).
>
> We use Date::Manip for this stuff BTW.  It slices, it dices.

Yup.   I'm familiar with it.  Use it in my own tv_update script.....

> >Your previous example invalidates your unambiguous assertion though.
> >In the US a time change happens at 2:00am.  Would --from 2:00
> >--until 3:00 be the first 2:00-3:00 single hour, the 2nd 2:00-3:00
> >single hour, or the inclusive two hour period??  ;-)
>
> The only difficulty there is in parsing the two dates.  To be really
> severe you could insist on full ISO 8601 dates with timezones for both
> values.  And this is indeed the underlying model.

I guess you are storing timezone in xml file aren't you......

> For user-friendliness you can allow strings like '2:00' or 'now' or
> 'tomorrow midnight' and convert these into full dates internally.
> Indeed, we do, because Date::Manip's ParseDate() groks all of these.
> Then if you want to specify the timezone you can write '2:00 UTC' or
> whatever.  No problem, and no special policy needed.
>
> >I agree; returning the smallest timeperiod possible from a source
> >would be usefull.
>
> If returning a variable number of days is useful, and returning a
> short period is useful, surely you agree that the simplest answer is
> to let the client say exactly what time period it is interested
> in?  Then the grabber can do its best to satisfy the request.

You didn't have to go far to convince me.  Mainly I just want a common 
interface across interfaces that lets me grab any single day starting at 
midnight (within the limits of the data source.)

> >Having the grabber write this granularity information to the xml
> >data would be usefull (from a client perspective).
>
> I don't think it belongs in the XML data (which describes television
> listings, not information about how to run the grabber) but there
> could certainly be some way for clients to query this information, if
> it's shown to be useful.

I may have been unclear.  The information I'm interested in here is an 
element to indicate what was fetched vs. what was requested (since they could 
be different due to granularity.)  Unless we expect to filter the fetched 
data to only the range requested.

-- 
--wduncan at fixme users.sourceforge.net
--