Thanks for a bug report. Could you check what /etc/localtime looks like, please? I guess it's not a soft link, in which case the timezone is clear, but otherwise at the worst case a file compare is done and the first file with the same content "wins".

>   $ ls -l /etc/localtime
>   .... /etc/localtime -> ../usr/share/zoneinfo/Europe/London

It is a soft link:

$ ls -l /etc/localtime 
lrwxrwxrwx. 1 root root 35 Apr 26  2013 /etc/localtime -> ../usr/share/zoneinfo/Europe/London

Weird, it looks quite the same as here. I even tried from scratch, replacing the file with this:

   # ln -s /usr/share/zoneinfo/Europe/London /etc/localtime

and it made it work properly, which means that the next start of the evolution the Europe/London had been shown in Edit->Preferences->Calendar and Tasks.

What do you want me to do to pinpoint the cause?

Created attachment 342217 [details]
test.c

Maybe a libical version you use can be the cause. At least I had such experience with the development version of it. Anyway, the attached test.c contains a comment at the top with the command line to use to compile and execute it. The code below it is the same as the one used by the evolution, only with added debugging prints. You might need to install glib2-devel and libical-devel to be able to compile the code.

It prints what timezones had been detected, then it shows how it found out the timezone it discovered, also with the location of it. Please run it, and let me know the result of it. No need to copy whole output of the run, enough might be lines which will mention your timezone location. Thanks in advance.

Relevant output:

system_timezone_read_etc_localtime_softlink: file:'../usr/share/zoneinfo/Europe/London' to tz:'(null)'
   system_timezone_is_valid: failed, tz is NULL
system_timezone_read_etc_timezone: 
   system_timezone_is_valid: failed, tz is NULL
system_timezone_read_etc_sysconfig_clock: 
   system_timezone_is_valid: failed, tz is NULL
system_timezone_read_etc_sysconfig_clock_alt: 
   system_timezone_is_valid: failed, tz is NULL
system_timezone_read_etc_TIMEZONE: 
   system_timezone_is_valid: failed, tz is NULL
system_timezone_read_etc_rc_conf: 
   system_timezone_is_valid: failed, tz is NULL
system_timezone_read_etc_conf_d_clock: 
   system_timezone_is_valid: failed, tz is NULL
system_timezone_read_etc_localtime_content: 
   system_timezone_is_valid: tz:'Europe/Jersey' is valid
main: found location:'Europe/Jersey'

Problem is that the /etc/localtime symlink is to a relative rather than absolute path then, with a leading '..', and e-cal-system-timezone.c  doesn't canonicalise the symlink path before testing with g_str_has_prefix (filename, SYSTEM_ZONEINFODIR "/")

Just tested, and switching the time zone via GNOME Control Centre time zone map results in similar relative symlinks, i.e. ../usr/share/zoneinfo/[time zone]

Ah, what a detail, relative path. I didn't notice it until you pointed into it. Thanks a lot for the investigation.

I didn't find any function to convert a relative path to an absolute path, thus I just special-cased the relative path existence.

Created commit 1874bc3 in eds master (3.23.4+)
Created commit 6aa5bfc in eds gnome-3-22 (3.22.4+)

realpath() in stdlib?

Thanks for the pointer. I've been looking for GLib wrapper, just to have something portable (which the stdlib should be, I know). Anyway, the above change is sufficient, at least for now, thus I'll keep it as it is.