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

[T Lee Davidson]

On 1/4/19 6:39 AM, Tobias Boege wrote:
> On Wed, 26 Dec 2018, T Lee Davidson wrote:
>> I am wondering why gb.web.feed is considered to be not yet stable. Are we waiting for anything specific before it is considered
>> stable (other than perhaps its developer to have more free time)?
>>

Thank you, Tobi, for that refresher with links to the relevant conversations all in one place.


> There are two "milestones" for the component:
> 
>   (1) Every RSS date must be formatted according to (a minor variant of)
>       RFC 822, which includes a timezone string. I think if you publish
>       e.g. local news, setting a timezone independent of the local one
>       is an important feature. I wanted to do this since the beginning [1]
>       but it *may* break the existing interface [2]:
> 
>         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.

I may be missing a particular need in regards to this, but I would just store dates as either RFC822 strings or rely on the
internal UTC representation and convert on retrieval/output (ie. a _get) as needed.

> 
>       I also remember issues with the date conversion, some of which got
>       fixed, but others not [3,4]. As I said 20 months ago, when this
>       is done, the component can be marked "Stable".

I find only one issue (see below *) with the questions you raised at your ref #3. Therefore, I am unsure exactly what needs to
be fixed. And, as much as I try, I cannot understand the need to separate the timezone (ref #4). It is available in both a
RFC822 date string and in the internal date representation as UTC.

In ToRFC822(), a pre-correction with, "System.TimeZone / 86400" is necessary due to the localization adjustment that the
subsequent Format() will apply. If this correction were not made prior to passing the date-time's component value to Format, the
resulting timezone would be off by -(System.TimeZone / 86400).

Regarding FromRFC822() _as I understand it_, since dates are stored internally as UTC [0] and the parameters for the Date()
function assume local time [1], "dDate -= Frac(Date(Now))" is necessary to adjust the localized dDate to a correct UTC
representation. Then, "dDate += GetRFC822Zone(aDate[6])" adjusts the (now correct UTC) date for the requested timezone
(summation is used due to fZone being defined as the appropriate positive or negative offset).

* However, there does seem to be an issue with FromRFC822():

[Code]
Public Sub Main()

Dim sDate As String = "Sun, 21 Apr 2019 05:00:00 GMT"
Dim dDate As Date

dDate = Date.FromRFC822(sDate)
Print CFloat(dDate)
Print Frac(dDate) * 24
Print Date.ToRFC822(dDate)
Print Date.ToRFC822(dDate, "EST")
Print Date.ToRFC822(dDate, "+0200")
' Get timezone From RFC8222 Date string
Print Split(sDate, " ").Last

End
[/Code]

[Result]
2490699.20833333
5.00000000372529
Sun, 21 Apr 2019 05:00:00 GMT
Sun, 21 Apr 2019 00:00:00 EST
Sun, 21 Apr 2019 07:00:00 +0200
GMT
[/Result : Correct]

With `Dim sDate As String = "Sun, 21 Apr 2019 00:00:00 EST"`
[Result]
2490698.79166667
18.9999999962747
Sat, 20 Apr 2019 19:00:00 GMT
Sat, 20 Apr 2019 14:00:00 EST
Sat, 20 Apr 2019 21:00:00 +0200
EST
[/Result : Incorrect]

Perhaps my understanding is quite faulty.


[snip]
> Regards,
> Tobi
> 
> [1] https://lists.gambas-basic.org/pipermail/user/2017-April/059815.html
> [2] https://lists.gambas-basic.org/pipermail/user/2017-April/059856.html
> [3] https://lists.gambas-basic.org/pipermail/devel/2017-July/006148.html
> [4] https://lists.gambas-basic.org/pipermail/user/2017-April/059915.html
> 


___
Lee

[0] http://gambaswiki.org/wiki/lang/type/date
[1] http://gambaswiki.org/wiki/lang/date