And then clicked “Time”
This is not an urgent issue. I can use another equal time zone.
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.
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.
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.
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.
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
Hi Steve,
My issue seems to be a combination of the issue you describe plus my timezone issue.
Note the time and date.
Thank you for the report. Very interesting bug indeed. I’m proposing a fix for it :
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 ; -)
3 Likes
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
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.Q: in what file are the timezones defined and their differences to UTC?
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
1 Like
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)
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.
1 Like
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)
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.
Not sure why this would have changed between 4.2 and 4.3 though. It worked perfectly on 4.2 and all previous versions I’ve used back to 2.
Between 4.2 and 4.3, the upstream tzdata package has been updated and it seems that Ireland time zone definition was changed for something that Qt 5.6 didn’t understand properly. It should be fixed in 4.4.
3 Likes
Just checked 4.2.0.19 (Verla)
The issue is not present