Re: [fpc-devel] New functions for time zone

[LacaK]

Michael Van Canneyt  wrote / napísal(a):



On Wed, 11 Jul 2012, LacaK wrote:


Hi *,
I noticed, that there was just added new functions for supporting TZ 
in rev. 21865 and 21866
Now function GetLocalTimeOffset: Integer returns offset *in minutes* 
and later in functions LocalTimeToUniversal and UniversalTimeToLocal 
are used commands to transform it to TDateTime using EncodeTime.

(f.e. EncodeTime(TZOffset div 60, TZOffset mod 60, 0, 0))

My idea is change function GetLocalTimeOffset: TDateTime to return 
TDateTime (offset in fraction of days - native FPC datetime format)

i.e. current implementation + "Result := Result / MinsPerDay"
I think, that it will be useful, because in real applications we will 
need on each usage transform minutes to use it in Datetime calculations.

(LocalDateTime := UTCDateTime - GetLocalTimeOffset;)

Then functions LocalTimeToUniversal and UniversalTimeToLocal will be 
simple addition or subtraction like:
function UniversalTimeToLocal(UT: TDateTime; TZOffset : TDateTime): 
TDateTime;

begin
 Result := UT - TZOffset;
end;

What do you think? It will simplify all.


There are 2 sides to this medal. The function returns a number of 
timezones;
This is usually expressed as a number of hours and minutes (the OS 
returns it so). The result is in 'natural' units.



AFAIK f.e. GetTimeZoneInformation under Windows return bias in minutes


Returning it as a timestamp - while useful by itself - seems rather odd.


May be, that I expressed it wrong


My proposal is like:

Windows:
function GetLocalTimeOffset: double;   <--
591
592var

593  TZInfo: TTimeZoneInformation;
594
595begin

596   case GetTimeZoneInformation(TZInfo) of
597 TIME_ZONE_ID_UNKNOWN:
598   Result := TZInfo.Bias;
599 TIME_ZONE_ID_STANDARD:
600   Result := TZInfo.Bias + TZInfo.StandardBias;
601 TIME_ZONE_ID_DAYLIGHT:
602   Result := TZInfo.Bias + TZInfo.DaylightBias;
603 else
604   Result := 0;
605   end;
+ Result := Result / MinsPerDay;
606end;

Unix:
   function GetLocalTimeOffset: double;   <--
1405
1406begin

+  Result := -Tzseconds / SecsPerDay;
1408end;


dateutil.inc:
function UniversalTimeToLocal(UT: TDateTime; TZOffset : double): TDateTime;
2467
2468begin

   Result := UT - TZOffset;
2476end;

Function LocalTimeToUniversal(LT: TDateTime;TZOffset: double): TDateTime;
2485
2486begin

  Result := LT + TZOffset;
2494end;

if TZOffset will be "day fraction" then we can simplyfy above mentioned 
functions, or am I wrong ?

Thanks
-Laco.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re[4]: [fpc-devel] New functions for time zone

[José Mejuto]

Hello FPC,

Wednesday, July 11, 2012, 5:41:45 PM, you wrote:

>> A:=Now;
>> B:=GetLocalTimeOffSet;
>> C:=LocalTimeToUniversal(A,B);
>> Will not return correct result in some mini-mili-microseconds slices
>> two times a year, and as more time passes between the assignements of
>> A and B (using a time field in databases, it could be days, years,
>> months...) the chances of a wrong conversion will raise a lot.
MVC> This is correct, but unavoidable without a huge
MVC> implementation like TZPascal...

That's completly overkill.

MVC> Even 'Now' itself is not 100% correct, since lots of computations are still
MVC> done after the time was gotten from the OS...

I think thew word here is "precise", now is not 100% precise, but it
is correct as it can describe a given moment in time, you know, the
most precise clock is the stopped one, it returns a 100% accurate time
2 times each day :)

-- 
Best regards,
 José

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Cross compiling x86 on amd64, linking to crtbegin.o etc.

[Sven Barth]

Am 11.07.2012 16:36, schrieb Konstantin:

Hello!

Free Pascal has been designed to run on several platforms on many
architectures which is a neat feature. The executable name is chosen
accordingly - ppc386, ppcx64 etc. to be able to have many at the same
time on the same system. When building from source it automatically
detects the platform on which it is running. Unfortunately, when
building on amd64 you end up with the ppcx64 compiler which can not
compile for x86 targets.

I'm using Free Pascal on Gentoo so I created ebuilds (see Gentoo bug
report here ) to compile
FPC on amd64 machines for x86 as well if desired. Currently this
involves compiling everything twice and then install it together. This
way the advantage of the CPU to be able to run code in 32 bit and 64 bit
on the same system can be used.

So first question, is there a better way instead of compiling everything
twice? Maybe something can be reused?


I'm not used to Gentoo's ebuilds, so I'll tell you from FPC's normal 
perspective:


if you do a "make all CPU_TARGET=i386" on a x86_64 Linux system then a 
x86_64 -> i386 cross compiler will be created with default system Linux 
and where the compiler binary will be called ppcross386 (instead of 
ppc386). [It works similar on Windows, other targets and other CPUs with 
the only exception that most non-i386 systems can not cross compile to 
i386, because of the missing Extended support; x86_64 on non-Windows can 
though] Only problem might be that the build process and/or the compiler 
does not find the correct binutils, so you might need to help it using 
BINUTILSPREFIX (e.g. "BINUTILSPREFIX=i686-linux-") and CROSSBINDIR (e.g. 
"CROSSBINDIR=/opt/gcc32" {just an example}). The crosscompiled compiler 
(and its units) is then installed using "make crossinstall 
CPU_TARGET=i386 INSTALL_PREFIX=/whereever/you/want".


Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re[3]: [fpc-devel] New functions for time zone

[Michael Van Canneyt]

On Wed, 11 Jul 2012, José Mejuto wrote:


Hello FPC,

Wednesday, July 11, 2012, 4:38:19 PM, you wrote:


Anyway the functions are nonsense as they accept a parameter for date
to be converted.

MVC> Not if they have the TZOffset parameter as well.
MVC> Without this information they are indeed nonsense.
MVC> That is why I added the parameter.

Well, I undertand it, I was only trying to note that this code:

A:=Now;
B:=GetLocalTimeOffSet;
C:=LocalTimeToUniversal(A,B);

Will not return correct result in some mini-mili-microseconds slices
two times a year, and as more time passes between the assignements of
A and B (using a time field in databases, it could be days, years,
months...) the chances of a wrong conversion will raise a lot.


This is correct, but unavoidable without a huge implementation like TZPascal...

Even 'Now' itself is not 100% correct, since lots of computations are still 
done after the time was gotten from the OS...


Michael.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re[3]: [fpc-devel] New functions for time zone

[José Mejuto]

Hello FPC,

Wednesday, July 11, 2012, 4:38:19 PM, you wrote:

>> Anyway the functions are nonsense as they accept a parameter for date
>> to be converted.
MVC> Not if they have the TZOffset parameter as well.
MVC> Without this information they are indeed nonsense.
MVC> That is why I added the parameter.

Well, I undertand it, I was only trying to note that this code:

A:=Now;
B:=GetLocalTimeOffSet;
C:=LocalTimeToUniversal(A,B);

Will not return correct result in some mini-mili-microseconds slices
two times a year, and as more time passes between the assignements of
A and B (using a time field in databases, it could be days, years,
months...) the chances of a wrong conversion will raise a lot.

MVC> If someone does not supply it, the current one will be taken; 
MVC> it is simply meant for current time operations.
MVC> The behaviour will be documented, and there will be a
MVC> remark about the TZ info being time dependent.
MVC> If someone doesn't know what he is doing, that's his problem.

Sure :) I had bitten that stone in the past ;)

-- 
Best regards,
 José

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re[2]: [fpc-devel] New functions for time zone

[Michael Van Canneyt]

On Wed, 11 Jul 2012, José Mejuto wrote:


Hello FPC,

Wednesday, July 11, 2012, 3:09:41 PM, you wrote:

MVC> There are 2 sides to this medal. The function returns a number of 
timezones;
MVC> This is usually expressed as a number of hours and minutes (the OS returns
MVC> it so). The result is in 'natural' units.
MVC> Returning it as a timestamp - while useful by itself - seems rather odd.

Returning it as a timestamp is nonsense, instead return a double
representing the day fraction, so 2 hours = 2 / 86400.

MVC> I'm also not quite sure what should be returned for
MVC> negative values of the timezone info.
MVC> 'today 23:00' or "Yesterday 23:00"
MVC> I think it should remain as it is, but if you want, we can create an extra
MVC> function 'LocalTimeOffset' in DateUtils that returns the same thing as a
MVC> TDateTime. This new function can then be used in conversion routines.

Anyway the functions are nonsense as they accept a parameter for date
to be converted.


Not if they have the TZOffset parameter as well.

Without this information they are indeed nonsense. 
That is why I added the parameter.


If someone does not supply it, the current one will be taken; 
it is simply meant for current time operations.


The behaviour will be documented, and there will be a remark about the TZ info 
being time dependent.
If someone doesn't know what he is doing, that's his problem.

Michael.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Cross compiling x86 on amd64, linking to crtbegin.o etc.

[Konstantin]

  
  
Hello!

Free Pascal has been designed to run on several platforms on many
architectures which is a neat feature. The executable name is chosen
accordingly - ppc386, ppcx64 etc. to be able to have many at the
same time on the same system. When building from source it
automatically detects the platform on which it is running.
Unfortunately, when building on amd64 you end up with the ppcx64
compiler which can not compile for x86 targets.

I'm using Free Pascal on Gentoo so I created ebuilds (see Gentoo
  bug report here) to compile FPC on amd64 machines for x86 as
well if desired. Currently this involves compiling everything twice
and then install it together. This way the advantage of the CPU to
be able to run code in 32 bit and 64 bit on the same system can be
used.

So first question, is there a better way instead of compiling
everything twice? Maybe something can be reused?

The second issue is more troublesome. In
compiler/systems/t_linux.pas the function
TLinkerLinux.WriteResponseFile generates a linker response file
where it gives absolute paths of crtbegin.o, crti.o, crtend.o and
crtn.o. The bad thing is that these paths are determined by the FPC
function librarysearchpath.FindFile and as this function does not
honor the target architecture. It always returns /usr/lib/. as
the default architecture version of these files is located there.
This of course fails when compiling x86 on amd64 Gentoo machine
where the 32 bit versions are in /usr/lib32/. and linking fails
due to invalid files.

So second question is, why are absolute paths used for crtbegin.o,
crti.o, crtend.o and crtn.o? When no paths are specified the linker
automatically chooses the right version and everything it seems to
be OK.

I made a patch for this (see the link to the ebuild above) to
specify the object files without paths and on Gentoo it is running
fine for me quite a while now. I can develop the 32 bit software on
any of my machines and it does not matter if I'm running 32 or 64
bit. Anyway, it would be a nice feature to have it included in
official source and Gentoo devs would like to know from upstream
what the "right" solution for this linking issue is. You are welcome
to add comments to the Gentoo bug report above.

Have fun,
Konstantin
  

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re[2]: [fpc-devel] New functions for time zone

[José Mejuto]

Hello FPC,

Wednesday, July 11, 2012, 3:09:41 PM, you wrote:

MVC> There are 2 sides to this medal. The function returns a number of 
timezones;
MVC> This is usually expressed as a number of hours and minutes (the OS returns
MVC> it so). The result is in 'natural' units.
MVC> Returning it as a timestamp - while useful by itself - seems rather odd.

Returning it as a timestamp is nonsense, instead return a double
representing the day fraction, so 2 hours = 2 / 86400.

MVC> I'm also not quite sure what should be returned for
MVC> negative values of the timezone info.
MVC> 'today 23:00' or "Yesterday 23:00"
MVC> I think it should remain as it is, but if you want, we can create an extra
MVC> function 'LocalTimeOffset' in DateUtils that returns the same thing as a
MVC> TDateTime. This new function can then be used in conversion routines.

Anyway the functions are nonsense as they accept a parameter for date
to be converted, and as noted in the bug report the functions must
only work over Now or NowUTC (or alike). IMHO is quite dangerous to
keep this functions as they are now in the base units, as the names
suggest that they will correctly convert any time UTC to a local time
or viceversa, so at least rename the function "GetLocalTimeOffset" to
"GetCurrentLocalTimeOffset" to note the "current" verb.

In the other hand this functions are not for local<->universal time
conversions, they displace times, calculate offsets and apply them, in
fact one function changing the sign of the offset will give the same
result as the other function.

As usual, this is just my opinion only...

-- 
Best regards,
 José

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New functions for time zone

[Michael Van Canneyt]

On Wed, 11 Jul 2012, LacaK wrote:


Hi *,
I noticed, that there was just added new functions for supporting TZ in rev. 
21865 and 21866
Now function GetLocalTimeOffset: Integer returns offset *in minutes* and 
later in functions LocalTimeToUniversal and UniversalTimeToLocal are used 
commands to transform it to TDateTime using EncodeTime.

(f.e. EncodeTime(TZOffset div 60, TZOffset mod 60, 0, 0))

My idea is change function GetLocalTimeOffset: TDateTime to return TDateTime 
(offset in fraction of days - native FPC datetime format)

i.e. current implementation + "Result := Result / MinsPerDay"
I think, that it will be useful, because in real applications we will need on 
each usage transform minutes to use it in Datetime calculations.

(LocalDateTime := UTCDateTime - GetLocalTimeOffset;)

Then functions LocalTimeToUniversal and UniversalTimeToLocal will be simple 
addition or subtraction like:
function UniversalTimeToLocal(UT: TDateTime; TZOffset : TDateTime): 
TDateTime;

begin
 Result := UT - TZOffset;
end;

What do you think? It will simplify all.


There are 2 sides to this medal. The function returns a number of timezones;
This is usually expressed as a number of hours and minutes (the OS returns 
it so). The result is in 'natural' units.


Returning it as a timestamp - while useful by itself - seems rather odd.

I'm also not quite sure what should be returned for negative values of the 
timezone info.
'today 23:00' or "Yesterday 23:00"

I think it should remain as it is, but if you want, we can create an extra 
function 'LocalTimeOffset' in DateUtils that returns the same thing as a 
TDateTime. This new function can then be used in conversion routines.


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New functions for time zone

[Mark Morgan Lloyd]

LacaK wrote:

Hi *,
I noticed, that there was just added new functions for supporting TZ in 
rev. 21865 and 21866
Now function GetLocalTimeOffset: Integer returns offset *in minutes* and 
later in functions LocalTimeToUniversal and UniversalTimeToLocal are 
used commands to transform it to TDateTime using EncodeTime.

(f.e. EncodeTime(TZOffset div 60, TZOffset mod 60, 0, 0))

My idea is change function GetLocalTimeOffset: TDateTime to return 
TDateTime (offset in fraction of days - native FPC datetime format)

i.e. current implementation + "Result := Result / MinsPerDay"
I think, that it will be useful, because in real applications we will 
need on each usage transform minutes to use it in Datetime calculations.

(LocalDateTime := UTCDateTime - GetLocalTimeOffset;)

Then functions LocalTimeToUniversal and UniversalTimeToLocal will be 
simple addition or subtraction like:
function UniversalTimeToLocal(UT: TDateTime; TZOffset : TDateTime): 
TDateTime;

begin
  Result := UT - TZOffset;
end;


Are there already cases where a TDateTime is used as an interval rather 
than for its original purpose? If not then I'd suggest that a new type 
is in order, taking a leaf from the book of at least some SQL 
implementations which have distinct timestamp and interval types.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] New functions for time zone

[LacaK]

Hi *,
I noticed, that there was just added new functions for supporting TZ in 
rev. 21865 and 21866
Now function GetLocalTimeOffset: Integer returns offset *in minutes* and 
later in functions LocalTimeToUniversal and UniversalTimeToLocal are 
used commands to transform it to TDateTime using EncodeTime.

(f.e. EncodeTime(TZOffset div 60, TZOffset mod 60, 0, 0))

My idea is change function GetLocalTimeOffset: TDateTime to return 
TDateTime (offset in fraction of days - native FPC datetime format)

i.e. current implementation + "Result := Result / MinsPerDay"
I think, that it will be useful, because in real applications we will 
need on each usage transform minutes to use it in Datetime calculations.

(LocalDateTime := UTCDateTime - GetLocalTimeOffset;)

Then functions LocalTimeToUniversal and UniversalTimeToLocal will be 
simple addition or subtraction like:
function UniversalTimeToLocal(UT: TDateTime; TZOffset : TDateTime): 
TDateTime;

begin
  Result := UT - TZOffset;
end;

What do you think? It will simplify all.

TIA
-Laco.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel