Ireland timezone

[menounsef]

REPRODUCIBILITY (% or how often): 100%
BUILD ID = OS VERSION (Settings > About product): 4.3.0.12
HARDWARE (XA2, X10, X10 II, …): XA2 Ultra
UI LANGUAGE: English
REGRESSION: (compared to previous public release: Yes, No, ?): Yes

DESCRIPTION:

The timezone for Ireland is incorrect

PRECONDITIONS:

STEPS TO REPRODUCE:

1. Settings
2. System
3. Time and date → click timezone → search for Dublin

EXPECTED RESULT:

Ireland should be GMT

ACTUAL RESULT:

Ireland is GMT +1

ADDITIONAL INFORMATION:

(Please ALWAYS attach relevant data such as logs, screenshots, etc…)

[adekker]

Ireland should be IST, UTC+01:00 in the summer and UTC+00:00 during the winter.
Here it does say the correct value in parentheses, and it does set the correct value when selected.
So it looks more like a positioning issue on this timezone page, Ireland should move to GMT +00:00 from 31 oct to the 27th of march.

[menounsef]

Hi, thanks for the reply.

It’s not just a display issue. It affects the calendar app, for example .

If I pick Ireland it all looks OK, but in this case the time is off by two hours.

I selected Ireland

[menounsef]

And then clicked “Time”

This is not an urgent issue. I can use another equal time zone.

[Seven.of.nine]

Did you try if a reboot does help and leads to a correct display in the clock app? Maybe you want to try and report here about the result.

[adekker]

You are correct about the regression remark, on my Jolla 1 with SFOS 3.4 Dublin show up below the GMT +0:00 header, and the clock displays the correct value when selected in the time and date screen.

[attah]

When i read on iana tzdata (which this is based on) there are some shenanigans with summer time being considered normal, and negative adjustment for winter(?) savings. There is also a mention about some parsers not supporting it. But i must admit i don’t understand the format to understand exactly what would go into the calculation - but none the less i assume the error stems from that.

PS: you can take screenshots with vol-up+vol-down.

[menounsef]

Ah ha! Thanks for the screenshot tip.

Reboot doesn’t help.

The strangest thing is, when using Ireland the main clock is correct, but the calendar will jump to tomorrow two hours early.

[Steve_Everett]

Could your problem with calendar entries bein set at the wrong time be similar to mine? Calendar Entries - Scheduled Time One Hour Later Than Set

[menounsef]

Hi Steve,

My issue seems to be a combination of the issue you describe plus my timezone issue.

Note the time and date.

[menounsef]

Now I go to calendar and select today

[dcaliste]

Thank you for the report. Very interesting bug indeed. I’m proposing a fix for it :

[qtdeclarative] Don't assume DST is +1 hour

The issue is in QML code when a JS Date object is created. The DST shift was assumed to always be one hour. But Ireland is defining DST during winter when the shift is -1. All in all, the time zone offset (+1 like in summer) + the wrong +1 DST shift resulted in a two hours shift during DST.

This bug was already corrected upstream in Qt5.9, see :
https://bugreports.qt.io/browse/QTBUG-56787

The description of the bug and the commit fix it are quite complex but they also involve interesting thought about issue in the ECMA definition of a Date object in javascript. And the fixing commit (https://github.com/qt/qtdeclarative/commit/2b8b7a162be52f8cd6c2bc39f498a1ddfb59dd68) also contains a nice notice about choosing an arbitrary date when building a time-only JS object related to Cassini. I encourage reading it ; -)

[tux_in_IE]

Yes it’s a quirk of Irish law that standard time is UTC+1 (in the summer) and winter time (UTC) is the “adjustment”, most (if not all!) other countries which use DST define the winter time as their standard time…
I only discovered today that my Xperia 10 stopped automatically checking for updates, so it’s still on 4.2 and this isn’t a problem on 4.2, I’ll upgrade to 4.3 today or tomorrow and see what happens.
Are you not using NTP though, OP? I have “Automatic Update” set and although Dublin, Ireland is visible it is greyed out. On 4.2 it makes no difference to the time if Automatic Update is set or not. Again I’ll check when I get 4.3

[poetaster]

For you ‘tldr’ people:

... ignore DST transitions before 1970, but even then zone transitions did
     * happen.  Some do happen at new year, others on DST transitions in spring
     * and autumn; so pick the three hundredth anniversary of the birth of
     * Giovanni Domenico Cassini (1625-06-08), whose work first let us
     * synchronize clocks tolerably accurately at distant locations.

[Seven.of.nine]

Q: in what file are the timezones defined and their differences to UTC?

[dcaliste]

They are in /usr/share/zoneinfo/, for instance /usr/share/zoneinfo/Europe/Dublin. You can use zdump to look at the binary file there.

[nemo@Sailfish ~]$ zdump --help
zdump: usage: zdump OPTIONS TIMEZONE ...
Options include:
  -c [L,]U   Start at year L (default -500), end before year U (default 2500)
  -t [L,]U   Start at time L, end before time U (in seconds since 1970)
  -i         List transitions briefly (format is experimental)
  -v         List transitions verbosely
  -V         List transitions a bit less verbosely
  --help     Output this help
  --version  Output version info

[Seven.of.nine]

Thank you @dcaliste !

Unfortunately this is a binary file with no human readable informations in it. ( I was curious and wanted to know if there is readable/editable information about the difference between UTC and local time, assuming that on Linux based systems system clock runs UTC)

[dcaliste]

I think SailfishOS is running like any desktop computer with respect to time zone and system clock.

The internal clock is stored as UTC and the system is exposing the time to users according to a given timezone. This time zone is defined by /etc/localtime. This is often a symbolic link to the time zone data under /usr/share/zoneinfo. On SailfishOS (and some other systems), there is an additional indirection from /etc to /var to allow to mount /etc read-only. The daemon responsible to update the time zone of the device is timed and is specific to SailfishOS, but it could have been Gnome settings or anything else.

The time zone can be overridden locally by setting the environment variable TZ. You can try TZ=Asia/Ho_Chi_Minh date on your device (or desktop), it will give you the current time in Vietnam.

[tux_in_IE]

Just zapped my previous post, I upgraded to 4.3 late last night and didn’t see any issues when I posted, but I do now.

• timezone Dublin, Ireland. NTP set (although this appears to make no difference)

• Clock on top of home screen and in Clock app are OK.

• All of the daily alarms I had set previously are displaying as 2 hours early. e.g. 0800 alarm displays as 0600

• When I set an alarm e.g. 1230 it appears in the list of alarms as 1030. But it still goes off at 1230.

• In Clock app - Alarms when setting a new alarm or editing an existing one, Sunday is the first day of the week. In this timezone Monday should be the first day of the week.

• The grid of existing alarms in Clock - Alarms still show the days of the week as five dots, gap, two dots (as if Monday is the first day of the week) but the pattern of set days corresponds to Sunday as the first day of the week. i.e. in edit alarm I set Thursday, in the grid of alarms it looks like it’s set for Friday.

• I set an alarm just now for Thursday only, it did not sound (presumably will sound tomorrow)

• In the Calendar, Monday correctly appears as the first day of the week. When setting an event, the wheel to set the time is correct but the event displays in the calendar as two hours early.

• I haven’t managed to get a calendar alert to work yet, I’ve tried setting them at the correct time, two hours early and two hours late but no alerts.

Setting the time zone to an equvalent e.g. Lisbon fixes all of these issues, but the alarms don’t display correctly until I quit the Clock app and restart it. Calendar alerts still don’t sound (even ones created after setting the time zone to Lisbon) and restarting the phone didn’t help.
Edit: scratch the last part, calendar alerts are working fine now (Canary Islands timezone)

[menounsef]

When the timezone is Ireland, the clock is correct in some aspects, but wrong in others. The system time (“date” at the prompt) is correct. It looks as if some of the GUI (Qt) components can’t cope with the oddity.

I’m currently using the Canary Islands timezone. It works perfectly.