Fails to properly decode slim tzdata

[Ken Murchison]

Hi Milan,

I'm wondering if this commit fixed one thing and broke another:

https://github.com/libical/libical/commit/c7e767bfe1d218aaf845686f9811195cecc7be2a 
<https://github.com/libical/libical/commit/c7e767bfe1d218aaf845686f9811195cecc7be2a>


I'm also wondering if this commit would fix the issue (I don't have time 
to test right now but can later this week):

https://github.com/eggert/tz/commit/7b4808dbf00896e606a0aa3b82ff9eb9b074323c 
<https://github.com/eggert/tz/commit/7b4808dbf00896e606a0aa3b82ff9eb9b074323c>


On 2/17/21 7:57 AM, Milan Crha wrote:
> 	Hello,
> a user reported an issue with timezone data in Flatpak on a Linux Mint
> machine, showing times one hour ahead when using libical 3.0.9. After
> some investigation I realized the org.gnome.Platform provides "slim"
> tzdata, which is used on the Linux Mint machine, instead of the "fat"
> tzdata, which is on the host system and which can be used on other
> systems (I tried on Fedora and Ubuntu). Why it does not use the host
> system tzdata I've no idea, but it at least shows a bug in the libical
> tzdata parsing.
>
> I filed a bug against the tzdata build for the Flatpak here:
> https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1202
>
> My helper application is attached. It uses Europe/Berlin timezone. When
> I have installed tzdata with `make ZFLAGS='-b fat' install`, then the
> time matches, but when I have tzdata installed with
> `make ZFLAGS='-b slim' install`, then the time is ahead by one hour.
>
> It seems the problem is with the last change only, at least according
> to the diff between the 'good' and the 'bad' time zone component. See
> attached tz.diff.
>
> I do not have any idea what and why the icaltzutil_fetch_timezone()
> does, I hope Ken will know what to do.
>
> 	Thanks and bye,
> 	Milan

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC