Wrong time zone on Linux Mint?

[Mr.Madguy]

I've finally made my project work, but I have one last problem. As this problem isn't related to 7z.so, I decided to make new thread for it.

I don't know, if it's Lazarus fault or Linux Mint fault. My time zone is UTC+3. But GetTimeZoneOffset reports -3. This causes following problem - LocalTimeToUniversal is reversed. For example current time is 20:00, UTC should be 17:00, but DateTimeToStr(LocatTimeToUniversal(Now)) reports 23:00. I.e. it adds 3 instead of subtracting it. I need to save time in UTC, but there is 6 hours difference due to this problem. Time zone is set correctly and time is shown correctly in system tray too, but every time I relog to Windows - there is the same 6 hours difference, that suggests, that something is wrong with TZ on Linux. Time is UTC in BIOS, but Linux Mint calculates UTC incorrectly, when it updates time via NTP, so it sets BIOS time incorrectly and Windows shows it incorrectly too, while it's not corrected via NTP.

What can be wrong? Can I fix it somehow? Or I should use crutch and replace LocalTimeToUniversal with UniversalTimeToLocal? LocalTimeToUniversal works correctly on Windows.

[lucamar]

I'm not sure whether this is your problem but if you're using both Windows and Linux in the same machine you should tell Linux that your (hardware) system clock is *not* UTC  but local, since Windows sets it that way (IIRC).

[Scoops]

Your hardware clock will flip out every time you switch from Windows to Linux Mint or vice versa,
as the one is using local time and the other is using UTC.

You'll have to switch Linux Mint to use local time.
On Linux Mint 18 and above you do this with the command: timedatectl set-local-rtc 1
(on earlier version of Mint you'd have to edit the file /etc/default/rcS but that won't work on Mint 18).

(If you're not an administrator you will need to prefix the command with sudo, so sudo timedatectl set-local-rtc 1 would be the command to use then.)

You can confirm the change was done by running grep LOCAL /etc/adjtime and that should reply "LOCAL".

With the system set to local time you should be aware (RTC = real-time clock, your hardware clock)

Cant remember where i got the above from but it works for me.

[sash]

I don't know, if it's Lazarus fault or Linux Mint fault. My time zone is UTC+3. But GetTimeZoneOffset

Then first, you need to make sure which timezone is currently set by simple 'date' command in terminal.

[Thaddy]

There is a fairly recent fix for the offset. What FPC version do you have? If its below 3.0.4. it definitely has a bug. 3.2.0 does not contain the bug.
Test added after original remark:
My test for UTC+2 gives 7-10-18 05:14:46 for UTC which is correct (7.14 local time) It may be in 3.0.4 fixes, but the fix is in 3.2.0 for sure.

[Mr.Madguy]

There is a fairly recent fix for the offset. What FPC version do you have? If its below 3.0.4. it definitely has a bug. 3.2.0 does not contain the bug.
Test added after original remark:
My test for UTC+2 gives 7-10-18 05:14:46 for UTC which is correct (7.14 local time) It may be in 3.0.4 fixes, but the fix is in 3.2.0 for sure.

I tested it on 3.0.0, as I'm at home now and I don't have latest Linux Mint here. So, I guess, it must be bug. But I use latest officially released version, i.e. 3.0.4. Dunno, if this bug is fixed there. As I've already said, it's Linux only problem. Everything works properly on Windows. I have 3.0.4 on Windows though.

Don't look at 5:29 - it's another bug, that is already fixed. Should be 17:29. It's +6 hours, so real time should be 11:29, as intended.

[Thaddy]

As I said it is a fairly recently fixed bug. Fairly recently means last three months, so 3.0.0.-3.0.4 have the bug. 3.2.0 and trunk do not have the bug.

[Renat.Su]

I also encountered various problems with time zones and different sense on different platforms. Therefore, I also add that for programs that actively uses various functions associated with different time zones, calendar, current time and other I recommend to use https://github.com/dezlov/PascalTZ

[Thaddy]

Not necessary for this issue: as I wrote it is fixed in 3.2.0 and trunk.
The library looks nice at first sight,  but overlaps mostly with Dateutils and I have some other issues:
It is a Tcomponent... Why such a heavy weight? Why not simply an advanced record?
It could have been written using all class functions instead of normal functions or by adding more class functions for much of its functionality.

[Renat.Su]

Not necessary for this issue: as I wrote it is fixed in 3.2.0 and trunk.
The library looks nice at first sight,  but overlaps mostly with Dateutils and I have some other issues:
It is a Tcomponent... Why such a heavy weight? Why not simply an advanced record?
It could have been written using all class functions instead of normal functions or by adding more class functions for much of its functionality.

For clarity, it's not my library. Lib is very useful, even though if the problem with the time zones is fixed, the operating system does not always correctly take into account the transitions to winter and summer time, depending on the calendar (if is not current date) and a year, and OS does not know about the time zones that are not available for the OS and them. Moreover, the library takes into account various historical transitions of time zones and other offsets. The library uses a table/database of time zones and their offsets in times

[Thaddy]

the operating system does not always correctly take into account the transitions to winter and summer time

This is also improved and that library does not make it any better:
As I explained before in another thread last year, this is governed by politics rather than nature and can change at any given point for any given region.
The only valid option to mitigate this is connecting to an NTP server and even that fails for some obscure regions.
There is no actual algorithm that can describe summer or wintertime for a region. It needs to be a database lookup, which is what NTP servers maintain or try to maintain.

If the library claims to do that - without connecting or maintaining an up-to-date static table per region - I would walk away from it: vapor ware... But it doesn't claim that.
It is just as prone to the above as the FPC methods are..... [edit] see https://en.wikipedia.org/wiki/Time_zone

E.g: even on windows, if you are not connected to a time server, the time goes wrong once the european parliament decides to abandon summer and winter time, which is a current proposal for 2019/2020.

There is actually an exact algorithm since the 1600's but it got out of use since the railways were introduced...and as such has no value...

[Renat.Su]

This is also improved and that library does not make it any better:

If you give me a cross-platform way to get local time for any region depending on GMT time and date [and even better "and year"] (i.e. GMT datetime), as well as time zone (i.e. string zone ID, not hour offset) I will be very grateful, as I will greatly simplify the code of my program.

As I explained before in another thread last year, this is governed by politics rather than nature and can change at any given point for any given region.

Oh, Yes, of course! I know that very well. In our region, in recent years, often changed the time offset and rules that even Windows OS and Ubuntu OS did not have time much for these changes.

The only valid option to mitigate this is connecting to an NTP server and even that fails for some obscure regions.
There is no actual algorithm that can describe summer or wintertime for a region. It needs to be a database lookup, which is what NTP servers maintain or try to maintain.

Of course, It need a database, I do not argue with this...
The PascalTZ uses a local database that is be taken from https://www.iana.org/time-zones periodically

If the library claims to do that - without connecting or maintaining an up-to-date static table per region - I would walk away from it: vapor ware... But it doesn't claim that.
It is just as prone to the above as the FPC methods are.....

The library claims that it works with a local database, which is written in the README.
I think when I decide to update the program code I will revise my code again and if it is possible to do without third-party libraries, then I will certainly try to do with the built-in FPC functions/classes. Perhaps this discussion will give me a reason to do so in the future, thank you

[Thaddy]

If you give me a cross-platform way to get local time for any region depending on GMT time and date [and even better "and year"] (i.e. GMT datetime), as well as time zone (i.e. string zone ID, not hour offset) I will be very grateful, as I will greatly simplify the code of my program.

Sysutils and dateutils are cross platform. There was just a bug (actually a regression). It is fixed.

The PascalTZ uses a local database that is be taken from https://www.iana.org/time-zones periodically

so needs a connection...?

The library claims that it works with a local database, which is written in the README.

Which is how all major OS's work... So maintain upgrades and FPC will use it...

[Renat.Su]

If you give me a cross-platform way to get local time for any region depending on GMT time and date [and even better "and year"] (i.e. GMT datetime), as well as time zone (i.e. string zone ID, not hour offset) I will be very grateful, as I will greatly simplify the code of my program.

Sysutils and dateutils are cross platform. There was just a bug (actually a regression). It is fixed.

I didn't know that in these fpc units had features that  can "to get local time for any region depending on GMT time and date as well as time zone alias". Thanks. I'll look at my leisure, but there are doubts.

The PascalTZ uses a local database that is be taken from https://www.iana.org/time-zones periodically

so needs a connection...?

No. The govenment  rules don't change that often. The base is loaded by reference and placed in a folder. Theoretically it is possible to make autoloadable, but I have no such need.

The library claims that it works with a local database, which is written in the README.

Which is how all major OS's work... So maintain upgrades and FPC will use it...

Ok. Good. My past experience has said that for non-current time zone and date it is not. But I'm not gonna argue.  Perhaps I am mistaken

[sash]

Yes, it is a bug.

Code: Pascal  [Select][+][-]

1. Writeln( GetLocalTimeOffset div 60 );

returns a negated value of what it should be.

OS: Ubuntu 18.04 bionic Kernel: x86_64 Linux 4.15.0-36-generic