[Gambas-user] gb.web.feed not stable yet?

[T Lee Davidson]

On 1/5/19 11:41 AM, Tobias Boege wrote:
[snip]
> 
> The need arises like this: when you read an RSS document, you likely want
> to get a Date, not a string describing the date. That's how we deal with
> dates in Gambas. But then, "time is absolute in Gambas", as often repeated
> by Benoît, i.e. a Date object points to a point in time, it has no need for
> a timezone component. The timezone must be dealt with in input/output,
> as you said. Now imagine I want to run an RSS-based newspaper "Magdeburg Times"
> for the German city I live in. My server happens to be located in Australia
> with an Australian locale and timezone. I want the news items to be PubDate'd
> according to what readers expect (Europe/Berlin), but e.g. the LastBuildDate
> should be in the local timezone of the server because that's an event actually
> happening on the server.

Apparently, I'm not understanding the scenario of your specific use example. If, say, subscribers of the "Magdeburg Times" will
be reading the feed from the publisher in Australia, it is up to the individual subscriber's feed reader to correctly interpret,
act upon, and/or display the appropriate RFC822 date fields LastBuildDate / Pubdate. Is it not?


> If that doesn't convince you, consider a feed aggregator service, which
> reads multiple feeds online (like all Gambas-related forums, blogs and the
> gitlab repo feed) and provides them as a single feed ("Gambas Today").
> All these feeds can have different timezones and the current implementation
> of gb.web.feed would just forget all of them. The dates displayed in the
> aggregated feed would point to the same *points in time* but they would
> all be relative to the timezone of the machine doing the aggregation.

Yes. And, again, I must be missing something because I simply don't see how is that a problem. Shouldn't the individual readers
convert the RFC822 date-time into a localized representation anyway? (Note: I am not a RSS expert!)


> My point is: timezones bear meaning

Yes. But they are all relative to UTC; and bear meaning only in the local timezone, IMO.


> and gb.web.feed should be able to
> preserve them. Thus I want the ability to *independently* set the timezone
> of every single Date field in the entire feed on output.

The only scenario in which I can imagine the need/desire for this would be in the case of a feed aggregator when the operator
wished to 're-feed' the items with PubDate timezone strings as originally published. In that case, I would simply store the
PubDate as a string. Thanks to FromRFC822() and ToRFC822(), conversions are painless.


> Yes, I know that making every Date into a (Date, TimeZone) compound
> may be too intrusive for something that people usually don't care about.
> But what else can I do? It would turn code like
> 
>   $hRssItem.PubDate = Now
> 
> into
> 
>   $hRssItem.PubDate.Date = Now      ' and optionally
>   $hRssItem.PubDate.Zone = "+0100"  ' or:
>   $hRssItem.Pub.Date = Now
>   $hRssItem.Pub.Zone = "+0100"
> 
[snip]
> 
> Since you sound like a potential user, what would you like to use?

My focus on use would be as a feed aggregator. And, no, I don't give a rat's a$$ about timezones as long as the time, in UTC, is
correctly preserved.

But, if I had to choose, I would have to go with PubDate.Date and PubDate.Zone as long as it is understood that PubDate.Date is
a UTC representation and PubDate.Zone is either the original publication tz (in the case of an aggregator) or the desired
publication tz (in the case of a feed generator).

And, since you have done the work on the component and generously shared it with the community, I'll be happy with whatever you
decide :-)


> I pushed some fixes, including this one, to gb.util in 3a16b32ad.
> The component now does the following, which feels correct to me:

The fixes you pushed appear to do essentially the same as I suggested here:
https://lists.gambas-basic.org/pipermail/user/2019-January/066131.html

And, FromRFC8222() appears to be working correctly.


___
Lee