Hi,

My local time zone is GMT +2, and have noticed that with V3.0.0, that the LocalTimeToUniversal() function is adding the offset instead of subtracting it:

uses  sysutils, dateutils;
var
   LocalTime: TDateTime;
begin
   LocalTime := Now();
   writeln('Offset     :', GetLocalTimeOffset());
   writeln('Local Time :', TimeToStr(LocalTime));
   writeln('UTC        :', TimeToStr(LocalTimeToUniversal(LocalTime)));
end.

Under 2.6.4 produces:

Offset : -120
Local Time : 05:29:13
UTC : 03:29:13

With 3.0.0:

Offset :-120
Local Time :05:31:16
UTC :07:31:16

Comparing dateutil.inc for both versions, in functions UniversalTimeToLocal() and LocalTimeToUniversal() the signs of the offsets have been changed

Thanks
Russell

Correct. This was in response to some bugreports.
IMO the offset should be 120, not -120.

Michael.

Dňa 28.6.2016 o 9:18 Michael Van Canneyt napísal(a):

IIRC original implementation was based on Microsoft logic of GetTimeZoneInformation, where is stated:

"All translations between UTC time and local time are based on the following formula:

UTC = local time + bias

The bias is the difference, in minutes, between UTC time and local time."

-Laco.

Russ Davies wrote

Hi, My local time zone is GMT +2, and have noticed that with V3.0.0, that the LocalTimeToUniversal() function is adding the offset instead of subtracting it:

i get the same over here...

Comparing dateutil.inc for both versions, in functions UniversalTimeToLocal() and LocalTimeToUniversal() the signs of the offsets have been changed

yeah, it does look backwards... i'm currently -0400 and the program says

2016 Jun 28 03:06:20 -0400
./timetest.2.6.4
Offset :240
Local Time :03:06:21
UTC :07:06:21

2016 Jun 28 03:06:21 -0400
./timetest.3.0.0
Offset :240
Local Time :03:06:22
UTC :23:06:22

i don't understand why LocalTimeToUniversal() isn't more simple... subtracting a negative is the same as adding the positive and subtracting a positive is, well, subtracting... it looks like they were trying to catch and protect from division by zero when the offset is 0 or there is no offset which results in the offset being 0... the following should work and be easier to follow...

Function LocalTimeToUniversal(LT: TDateTime;TZOffset: Integer): TDateTime;
begin
   if (TZOffset  0) then
     Result := LT - EncodeTime(TZOffset div 60, TZOffset mod 60, 0, 0)
   else
     Result := LT;
end;

at least they're not trying to determine which timezone specification is in use... the two that i know of are backwards from each other... using the standard (POSIX??) form, i'm EST5EDT (-0500 and -0400) but using the other form (America/New York or Etc/GMT-5 ???) i'm 0500 and 0400 which means that the formula for the standard form is subtracting whereas the other one is adding when going from local time to GMT time... yeah, it gets really twisted and using the wrong form, while correct for your area, can result in time being off by 12 hours (IIRC)...

Michael Van Canneyt wrote

On Tue, 28 Jun 2016, Russ Davies wrote:

[...]

so GetLocalTimeOffset() is wrong and has been for a long time??

cat ~/development/fpc/2.6.4/rtl/unix/sysutils.pp
cat ~/development/fpc/3.0.0/rtl/unix/sysutils.pp
cat ~/development/fpc/fixes_3_0/rtl/unix/sysutils.pp

function GetLocalTimeOffset: Integer;
begin
  Result := -Tzseconds div 60;
end;

Nono. I spoke from (fuzzy) memory, but now I did some deeper investigation.

FPC 3.0 indeed contains a bug. This has meanwhile been fixed.

If I compile the program with trunk, I get:

home: >fpc tt.pp
home: >./tt
Offset :-120
Local Time :10:53:16
UTC :08:53:16
home: >date --utc
Tue Jun 28 08:53:25 UTC 2016
home: >date
Tue Jun 28 10:53:29 CEST 2016

So the output is correct in trunk, and the bug has been fixed. I expect the fix to be in 3.0.2.

My apologies for the confusion.

Michael.

It doesn't look like this fix (r31356) has been merged into fixes_3_0, or am I missing something?

Henry

i think you're right.

Tested with 3.0.x fixes branch in windows 10 :

C:\Users\thouli\Programming>fpc -iV
3.0.1

C:\Users\thouli\Programming>testLocaltime.exe
Offset :-180
Local Time :19:25:35
UTC :22:25:35

C:\Users\thouli\Programming>wmic path win32_currenttime Day DayOfWeek Hour Milliseconds Minute Month Quarter Second WeekInMonth Year
29 3 19 25 6 2 39 5 2016

C:\Users\thouli\Programming>wmic path win32_utctime Day DayOfWeek Hour Milliseconds Minute Month Quarter Second WeekInMonth Year
29 3 16 25 6 2 45 5 2016

regards,

it doesn't look right over here, either...

./timetest.2.6.4
Offset :240
Local Time :14:50:18
UTC :18:50:18

./timetest.3.0.0
Offset :240
Local Time :14:50:18
UTC :10:50:18

./timetest.3.0.1
Offset :240
Local Time :14:50:18
UTC :10:50:18

./timetest.3.1.1
Offset :240
Local Time :14:50:18
UTC :18:50:18

date --utc
Wed Jun 29 18:50:18 UTC 2016

Does this have to do with some questionable Microsoft formulae which prompted this query -
http://stackoverflow.com/questions/2779948/subroutine-to-apply-daylight-bias-to-display-time-in-local-dst ?

vfclists . wrote

Does this have to do with some questionable Microsoft formulae which prompted this query - http://stackoverflow.com/questions/2779948/subroutine-to-apply-daylight-bias-to-display-time-in-local-dst

Hello,

Only Now() can be converted to UTC using that formula, and only UTC Now can be converted back to your local zone time, any other time/date conversions could be wrong because you do not know how to convert from UTC to Accra (stackoverflow thread) unless your system is located in Accra, and as noted only "NOW()" values are valid.

For inter-zone-across-history time conversions another routines and "databases" must be used.

FPC 3.0.0 produces incorrect results.

FPC 3.0.1 r34023 and FPC 3.1.1 r34024 produce correct results.

Tested on Windows 7.

FPC 2.6.4
Offset :-60
Local Time :23:06:27
UTC :22:06:27 (CORRECT)

FPC 3.0.0
Offset :-60
Local Time :23:07:03
UTC :00:07:03 (WRONG)

FPC 3.0.1 r34023
Offset :-60
Local Time :23:21:52
UTC :22:21:52 (CORRECT)

FPC 3.1.1 r34024
Offset :-60
Local Time :23:24:22
UTC :22:24:22 (CORRECT)

Regards,
Denis

Thanks Marco for merging it last night.

Henry

Henry Vermaak wrote

On Wed, Jun 29, 2016 at 05:09:54PM +0100, Henry Vermaak wrote: > On Tue, Jun 28, 2016 at 10:56:30AM +0200, Michael Van Canneyt wrote:

[...]

yes! excellent!

./timetest.2.6.4
Offset :240
Local Time :11:44:21
UTC :15:44:21

./timetest.3.0.0
Offset :240
Local Time :11:44:21
UTC :07:44:21

./timetest.3.0.1
Offset :240
Local Time :11:44:21
UTC :15:44:21

./timetest.3.1.1
Offset :240
Local Time :11:44:21
UTC :15:44:21

date --utc
Thu Jun 30 15:44:21 UTC 2016

wrong time calculations are very bad for tracking space born objects ;)