[Gambas-user] New component gb.rss to generate and parse RSS documents

[Benoît Minisini]

Le 18/04/2017 à 19:44, Tobias Boege a écrit :
> On Sun, 16 Apr 2017, Benoît Minisini wrote:
>> Le 02/04/2017 à 18:07, Tobias Boege a écrit :
>>>
>>>   * The date conversion routines ignore timezones completely, because
>>>     I have no clue about working with timezones in Gambas.
>>>
>>
>> Hi, Tobias.
>>
>> I have added in revision #8122 two functions to the gb.util component:
>>
>> Date.ToRFC822(), to convert a Gambas date/time value to its RFC822
>> string representation, with the timezone.
>>
>> Date.FromRFC822(), to do the contrary.
>>
>> Tell me if you can use them, and if you need me to add the same
>> functions for RFC3339 date format used by Atom.
>>
>
> Thanks for these. Reading the code (not testing it yet), I noticed four
> things:
>
>   * The weekday and second parts in the format are optional in the RFC
>     but mandatory in your parser.
>
>   * The year is a 2-digit number in the RFC. The RSS spec says it prefers
>     4 digits. My current parser in gb.web.feed supports both, but treats
>     2-digit years XY as 19XY (which I think is the most sensible
>     interpretation with respect to the RFC but sadly excludes publication
>     dates for news items near Christ's birth).
>
>   * There is no consistency check in the parser if, in case a weekday is
>     given, it matches the weekday of the date, like
>
>       Fri, 18 Apr 2017 12:00:00 GMT
>
>     would be invalid by the RFC ("5.2 SEMANTICS"), because the 18 Apr 2017
>     is a Tuesday.
>
>   * At one point you use Format$(..., "hh:nn:ss") which I think may be
>     dangerous, because Format$() (as per docs) replaces ":" by the locale-
>     specific time separator. I don't know if there are locales where this
>     is different from ":", but the RFC requires it to be ":" exactly.
>
> My parser does these four things. If you want to add them, the gb.web.feed
> code is sufficiently commented in the relevant places.

OK, I will look at it.

>
> As for Atom, I don't have a definite plan for when I'll add these classes
> (haven't even read the specs yet). I don't need the functions right now,
> at least.
>
> About the incorporation of timezones in gb.web.feed (the last thing before
> I mark the component as "Unfinished but stable"), my plan is to replace the
> Date variables in the Rss* classes by an RssDate compound, consisting of a
> normalised Date and a Timezone string (or constant), with an "apply timezone"
> method probably. If you have a better idea, please let me know.

What for? Timezone is only needed when dealing with Date as strings. 
Internally, all Date values should be stored UTC. In computing, time is 
absolute.

In other words, every date value has as many string representations as 
the number of possible timezones.

Regards,

-- 
Benoît Minisini