Gambas 3.10 - gb.web.feed

Gambas 3.10 - gb.web.feed

On Sat, 01 Jul 2017, Beno�t Minisini via Gambas-devel wrote:
> I will have some time next week, and I want to release Gambas 3.10.

Hi Benoit,

Gambas 3.10 would include the new gb.web.feed, right? I have some local
changes pending which better be committed before the component is first
included in a stable version.

As I mentioned earlier, I want Date values in RSS to be accompanied by
an RFC822 timezone string, because I want to give the user a way to
specify the timezone string when they create RSS documents (e.g. an RSS
feed of a local newspaper in Germany should not have the timezone of
the US-located server machine where the feed is put together, but the
German timezone relevant to the article).

I need the following:

1. A way to get the timezone string out of the RFC822 parser in gb.util.
2. Two functions which convert between RFC822 timezone string and
a numeric representation (number of seconds from UTC?) I believe
those functions are already in gb.util, but Private.
3. An RFC822 timezone string for the local system timezone, as a
reasonable default when the user gives no timezone.
4. Functions which convert a (date, timezone) pair, which is to be
understood as "<date> is in/relative to <timezone>" to another
timezone.

I think if 1. and 2. are there, I can implement 3. and 4. by myself.
Having 4. would give me a clean conscience, as I intend to store the
timezone inside the component just as an RFC822 timezone string and
let the user handle calculations with timezones if they need it.
Point 4. then gives the user the needed primitives.

Please also look at [1] where I listed some doubts I have about the
current RFC822 functions in gb.util.

Re: Gambas 3.10 - gb.web.feed

On Sat, 22 Jul 2017, Benoît Minisini wrote:

> Le 01/07/2017 à 21:46, Tobias Boege a écrit :
> > On Sat, 01 Jul 2017, Beno�t Minisini via Gambas-devel wrote:
> > > I will have some time next week, and I want to release Gambas 3.10.
> >
> > Hi Benoit,
> >
> > Gambas 3.10 would include the new gb.web.feed, right? I have some local
> > changes pending which better be committed before the component is first
> > included in a stable version.
> >
> > As I mentioned earlier, I want Date values in RSS to be accompanied by
> > an RFC822 timezone string, because I want to give the user a way to
> > specify the timezone string when they create RSS documents (e.g. an RSS
> > feed of a local newspaper in Germany should not have the timezone of
> > the US-located server machine where the feed is put together, but the
> > German timezone relevant to the article).
> >
> > I need the following:
> >
> > 1. A way to get the timezone string out of the RFC822 parser in gb.util.
> > 2. Two functions which convert between RFC822 timezone string and
> > a numeric representation (number of seconds from UTC?) I believe
> > those functions are already in gb.util, but Private.
> > 3. An RFC822 timezone string for the local system timezone, as a
> > reasonable default when the user gives no timezone.
> > 4. Functions which convert a (date, timezone) pair, which is to be
> > understood as "<date> is in/relative to <timezone>" to another
> > timezone.
> >
> > I think if 1. and 2. are there, I can implement 3. and 4. by myself.
> > Having 4. would give me a clean conscience, as I intend to store the
> > timezone inside the component just as an RFC822 timezone string and
> > let the user handle calculations with timezones if they need it.
> > Point 4. then gives the user the needed primitives.
> >
> > Please also look at [1] where I listed some doubts I have about the
> > current RFC822 functions in gb.util.
> >
> > Regards,
> > Tobi
> >
> > [1] https://sourceforge.net/p/gambas/mailman/message/35810371/> >
>
> Sorry, I forgot to deal with your requests.
>

And I came back from vacation just recently. As I see 3.10 wasn't released
yet. I'll try to push the changes today, if we can agree on them.

> You should internally use Gambas date, not strings, as Gambas date are
> internally UTC timestamps.
>
> The trick is that when you make a date with Date(Year, Month, ...), the
> values you are giving are in the local timezone.
>
> This is the reason why I'm substracting Frac(Date(Now)): it moves the date
> to the UTC time zone (as Now is in local time, the fractional part of
> Date(Now) converted to float is the timezone).
>
> Frac(Date(Now)) and -(System.TimeZone / 86400) are the same value (up to the
> 4th decimal digit, because of different precision).
>
> And isn't the timezone mandatory in a RFC822 date?

Yes, the timezone is mandatory there.

So, how about this: I make a class called RssDate where I store a UTC-based
timestamp (aka Date) and a timezone string. As I mentioned before, I think
the timezone string is necessary to let the user specify what timezone the
date will be printed in.

When an RFC822 date is read, I want to have its timezone string and the
timestamp of that date converted to UTC. When an RFC822 date is written,
I take the UTC timestamp and convert it to the string representation in
the timezone that the user wants to print the date in.

Re: Gambas 3.10 - gb.web.feed

Le 28/07/2017 à 15:57, Tobias Boege a écrit :
>>
>> Sorry, I forgot to deal with your requests.
>>
>
> And I came back from vacation just recently. As I see 3.10 wasn't released
> yet. I'll try to push the changes today, if we can agree on them.
>

I go to vacation tommorow, and come back next week. So I think I will
make the release in a week, so that you have more time.

>> You should internally use Gambas date, not strings, as Gambas date are
>> internally UTC timestamps.
>>
>> The trick is that when you make a date with Date(Year, Month, ...), the
>> values you are giving are in the local timezone.
>>
>> This is the reason why I'm substracting Frac(Date(Now)): it moves the date
>> to the UTC time zone (as Now is in local time, the fractional part of
>> Date(Now) converted to float is the timezone).
>>
>> Frac(Date(Now)) and -(System.TimeZone / 86400) are the same value (up to the
>> 4th decimal digit, because of different precision).
>>
>> And isn't the timezone mandatory in a RFC822 date?
>
> Yes, the timezone is mandatory there.
>
> So, how about this: I make a class called RssDate where I store a UTC-based
> timestamp (aka Date) and a timezone string. As I mentioned before, I think
> the timezone string is necessary to let the user specify what timezone the
> date will be printed in.
>
> When an RFC822 date is read, I want to have its timezone string and the
> timestamp of that date converted to UTC. When an RFC822 date is written,
> I take the UTC timestamp and convert it to the string representation in
> the timezone that the user wants to print the date in.
>
> If that sounds reasonable, I can get to work now.
>
> Regards,
> Tobi
>

Why do you need the timezone part of the RFC822 date as a string? Why
not just using Gambas Date and the Date.ToRFC822() / Date.FromRFC822()
functions?

Re: Gambas 3.10 - gb.web.feed

On Fri, 28 Jul 2017, Benoît Minisini via Gambas-devel wrote:

> > Yes, the timezone is mandatory there.
> >
> > So, how about this: I make a class called RssDate where I store a UTC-based
> > timestamp (aka Date) and a timezone string. As I mentioned before, I think
> > the timezone string is necessary to let the user specify what timezone the
> > date will be printed in.
> >
> > When an RFC822 date is read, I want to have its timezone string and the
> > timestamp of that date converted to UTC. When an RFC822 date is written,
> > I take the UTC timestamp and convert it to the string representation in
> > the timezone that the user wants to print the date in.
> >
> > If that sounds reasonable, I can get to work now.
> >
> > Regards,
> > Tobi
> >
>
> Why do you need the timezone part of the RFC822 date as a string? Why not
> just using Gambas Date and the Date.ToRFC822() / Date.FromRFC822()
> functions?
>

When I read an RSS document into Rss objects, I want to retain the timezone
strings used in the original document. If I don't know the timezone string,
I would have to reset all timezones to UTC. The dates will be correct but
the timezone in the string representation of the date will have changed
(and the timezone may carry a meaning). It would be nice just to be able
to replicate a document that I have just read into gb.web.feed, too.

First of all, the time components are not Format$(..., "00")'d, so they
print single digits where the RFC requires 2 digits. And second, shouldn't
reading a GMT date and putting it into GMT again result in the same string
that we started with? The 4 hour different is likely because I'm in +0200.