The guest time zone effects guests, and is not necessarily the time zone that registered users will get.
We use some JavaScript and the local time of the registering user to figure it out automatically. This involves looking at the timezone UTC offset at January 1st and June 1st. The combination of these two values should tell us what the UTC offset is normally vs what it is during DST.
I
think the discrepancy here might be related to changes to MSK Moscow Time in 2011 and 2014. I believe we may be using the data from what was valid in 2011 which, correct me if I'm wrong, was permanent all-year round UTC +4:00.
JavaScript:
'-180,-240' : 'Africa/Nairobi',
'-180,-180' : 'Africa/Nairobi',
'-210,-270' : 'Asia/Tehran',
'-240,-240' : 'Europe/Moscow',
You can see here that Europe/Moscow is defined as having a UTC +4 (240 minutes) offset in both standard and summer time. But I think this changed again in 2014 and became all-year round UTC +3:00.
Africa/Nairobi is defined as having UTC +3 (180 minutes) offset in both standard and summer time. East Africa Time is therefore exactly the same as Moscow Time.
So the choices really are we either replace Africa/Nairobi with Europe/Moscow which would be correct for your users in Moscow but incorrect for other customers who have users in the Africa/Nairobi timezone or we just remove Europe/Moscow from the list and just accept that although your users will see the wrong
name for the timezone, their actual times across the forum will be the same regardless because (at least currently) EAT is the same as MSK.
I know what your preference will be, of course, but we have to weigh up what is best generally.
As a workaround for now, you could simply change the contents of the
utc_plus_0300_baghdad
phrase to the following (or whatever you think is appropriate):
Code:
(UTC+03:00) Moscow, St. Petersburg, Volgograd