Roundcubemail: Inconsistent offset for various time zones

[navossoc]

Hi, I was wondering if there is any specific reason why the time zone is calculated on a fixed date (December 21) and not using the current date...

https://github.com/roundcube/roundcubemail/blob/6d19d1466e9bafc0de0ef19e6ed661f5a119fa56/program/steps/settings/func.inc#L212

For example:
Here on Brazil (America/Sao_Paulo) on this date (21/12/2018) we have daylight saving time enabled. Then GMT -03:00 becomes GMT -02:00.
I was looking at the time zone list a few months ago and could not find my TZ on the list, this is very confusing (at least for me).

I made a patch and I'm manually applying it to every release since v1.3.5.

--- a/program/steps/settings/func.inc
+++ b/program/steps/settings/func.inc
@@ -222,7 +222,7 @@
                 foreach (DateTimeZone::listIdentifiers() as $i => $tzs) {
                     try {
                         $tz      = new DateTimeZone($tzs);
-                        $date    = new DateTime(date('Y') . '-12-21', $tz);
+                        $date    = new DateTime('now', $tz);
                         $offset  = $date->format('Z') + 45000;
                         $sortkey = sprintf('%06d.%s', $offset, $tzs);
                         $zones[$sortkey] = array($tzs, $date->format('P'));

Thanks.

[alecpl]

That is a question. Should we display standard time offset or current time (whether it is ST or DST) offset. @thomascube your opinion?

[navossoc]

Well, I had the same question.
To be honest I don't know what is better either.

If I need to choose between Dec/21 and current date, I prefer the _second option_.
It's less confusing, since I _probably_ know that DST is on (today) and not on a weird/future date.

For example:

This is how Android display it:

There is a third option:
Windows has a different approach, it shows the timezone fixed even if DST is on/off.

I'm not sure how Linux displays the time zone, I can not check it now, but I think it would be interesting to see too.

If the third option is available too (Windows UTC), I rather prefer this one.

I did not do this (3rd option) because it needed more code changes and I was trying to keep the patch as simple as possible.

[thomascube]

The idea was to display standard time offset. That's why that particular date was chosen (at least in Europe, this is in ST) but that apparently doesn't apply to all timezones.

Therefore I'd follow @navossoc's suggestion and use the current date. I don't think PHP's date functions allow to get the standard timezone offset regardless of the given date.

[alecpl]

So, Android displays current offset, Windows ST offset. In KDE timezone selector does not display the offset at all ;) As the intention was to display ST offset (and it worked for european countries already), I would keep that way.

I guess we could loop on each month starting from 'now' until we find non-DST date and use offset of that. Right?

[navossoc]

@thomascube Last time I checked, there is not a built in way to do that.

http://php.net/manual/en/datetimezone.getoffset.php
It requires a date and you can't know beforehand if that date has DST on or off.

You may try:
http://php.net/manual/pt_BR/datetimezone.gettransitions.php

But I think it is a little bit overkill, since you need to query a date span and again you don't any clue when it can start or end.

There is 400+ entries on that time zone list.

@alecpl I don't about Europe but at least here, DST start and end dates are subject to change.
So we had a few issues with wrong clock times.

[]'s

[alecpl]

@navossoc I didn't mean to not change the current behavior as it is obviously wrong. I meant to keep displaying ST offset and make it working for all timezones. And I proposed how to do this.

[navossoc]

@alecpl I know, but the problem is: if they are subject to change, you can get the same issue again of displaying the wrong offset.

So, you'll need a proper installation of php with a recent tzdata (or something like that) for your idea to work.

I think that is why people are moving from GMT to UTC.

Unfortunately, time zones are a mess...

PS: I'll dig a little bit more on this subject later, if I found something interesting I bring to discussion.

[alecpl]

We could present the list completely different, we could implement searching, but I was looking for an immediate solution. Displaying offset of 'now' is worse than my proposal because it also depends on up-to-date tzdata and does not ignore DST.

[navossoc]

@alecpl To be honest, I think both options are (leave as it is or 'now'), but hey, it works 😃 .

From what I have been able to infer from our "conversation":
In Europe, the daylight-saving time interval is not as easy to change as here, is it?

Then, the second method has a slight advantage. If the tzdata is updated, you may view the correct offset or in worst case (for me) there will be an error of a few weeks of difference.
While for Europe it probably will not make any difference, since it doesn't change a lot (or at all?).

[alecpl]

Fixed.