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

[Tobias Boege]

On Sat, 05 Jan 2019, T Lee Davidson wrote:
> 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?
> 

Good point. My feed reader indeed does that (it even stores dates as integers
in its database -- although I don't see how it remembers which articles I read
during daylight-saving time because some timestamps have +0200).

Then, my final appeal is this: the RSS specification requires dates to be
strings *with* a timezone component instead of a UNIX timestamp or a UTC date.
What can be controlled in a file format should be controllable by an
implementation of that format.

> > 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 :-)
> 

It's good that you wrote the first and third paragraph because I prefer the
shorter Pub.Date and LastBuild.Date ways (it's good that all date-like fields
end in "Date" in RSS), which are now in master. The component is marked as
"Stable" as well.

If you don't care about timezones, all you have to do is, *almost* like before
but with an additional dot:

  $hRssItem.Pub.Date = Now

When reading an RSS document, you get the date which points to the correct
point in time via $hRssItem.Pub.Date and the timezone it was originally
serialised with in $hRssItem.Pub.Zone, which will be used again when you
write an XML document from it to create the same string you read. If the
date is not given, it defaults to the moment the date is needed (i.e. the
XML document is written) and the timezone is the local one by default.

In short: if you don't want to set special timezones, you never have to
write "Zone". And if you run older code with the now-stable interface one
gets an error like "symbol PubDate not found" which hopefully inspires to
look into the documentation, which I updated in the sources. Hopefully it
makes its way into the online docs shortly. I don't remember if someone
has to flip a switch or if there is a cronjob or, meanwhile, git hook
which does it.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk