Now KStars uses its own system for handling time zones and daylsight saving time (DST) rules. This is wrong for several reasons: 1. It's not correct. Time zones and DST change over time. KStars cannot handle it. 2. They'll become out of date when rules change. In fact they are out of date already. 3. It's very complex. We canot make it better than it's already done. It's just a wasted effort. In my opinion KStars should store time internally as julian date or something similar. It's simple since it doesn't have to deal with abrupt jumps in time when DST kicks in. It's just a number so it's easy to manipulate time intervals. Transformation to/from YYYY:MM:DD HH:MM:SS is required only when time is presented/being read from user and could be done on demand. On downside it require overhaul of all time handling in kstars.
*** Bug 297704 has been marked as a duplicate of this bug. ***
Yes. I agree with this bug. Also, we should not have our own set of DST rules at all, but rather just get them from the tzdata package.
5 years later, I dig up this bug report. I had an issue with asteroid position but it was due to 1 hour drift with kstars time. Set your position in kstars (paris for example). Set kstars to be now. Then change date of your operating system in order to start or end the daylight saving time. Then set kstars to now. Kstars will not applied DST change and shows a gap of 1 hour in my case. In the location windows, the DST parameters for Paris is EU and shows the same start time and revert time which is wrong. DST 2017 (France). Start: 02:00 sunday 26 march End: 03:00 sunday 29 october TZ rules are hardcoded in locationdialog.cpp and there is a file named TZrules.dat with data duplicated.
Created attachment 107826 [details] Patch to change EU TZData according to France Not sure this is the better way to do it because it's hard coded The rule is for EU countries but is this rule matching each EU country. This patch fix DST for French user.
I agree with the concept of using the current system settings, however, surely there is a work around for this. The current DST rule:AU setting has been wrong for years and I cannot see any way to correct it. If the rules are not going to be kept up-to-date then adding a DST flag might be another option.
What's the correct rule for AU?
Jasem, According to the government web site, the current rule is. Daylight Saving Time begins at 2am on the first Sunday in October, when clocks are put forward one hour. It ends at 2am (which is 3am Daylight Saving Time) on the first Sunday in April, when clocks are put back one hour. Regards Paul > On 24 Oct 2017, at 5:50:23 pm, Jasem Mutlaq <bugzilla_noreply@kde.org> wrote: > > https://bugs.kde.org/show_bug.cgi?id=291203 > > --- Comment #6 from Jasem Mutlaq <mutlaqja@ikarustech.com> --- > What's the correct rule for AU? > > -- > You are receiving this mail because: > You are on the CC list for the bug.
Although Bug #383682 is currently closed, another problem raised there - DST rule of South Korea is incorrect - is still not fixed. Also there are some external report about wrong time zone [1] too. Is there a reason not using tzdata at all? Maintaining the own database won't make sense unless having a good reason. [1] https://www.indilib.org/forum/ekos/3226-kstars-local-time-offset-wrong.html https://indilib.org/forum/general/2272-kstars-clock-and-utc-offsets.html
We need a cross-platform method that works on Windows, Linux, and MacOS. And then we need someone to integrate that to KStars, it's not simply a matter of changing the source. So both Hong Kong and China DST rules should be removed? I checked and it appears they don't use DST at all for MANY years.
Git commit c0f8d5c4ffa75c1a700231a885ca167fbee1110b by Jasem Mutlaq. Committed on 21/10/2019 at 19:28. Pushed by mutlaqja into branch 'master'. Fix TZ rules for a few countries. FIXED-IN:3.3.7 M +6 -25 kstars/data/TZrules.dat M +- -- kstars/data/citydb.sqlite https://commits.kde.org/kstars/c0f8d5c4ffa75c1a700231a885ca167fbee1110b