Can someone apply the patch for adding %DATETIME%, if there are no objections?

Denis

I don't think this is a good idea.

1. The TDateTime format is not a basic format of the language. It is an agreement on how to encode date/time information in a double.

You now make the compiler dependent on this "agreement", promoting TDateTime to a compiler-recognized type.

2. Some targets do not even have floats. That will cause problems as well.

Michael.

Just add something like this to your compile process:

echo \'`date`\' > fpc_timestamp.inc

Then:

begin
  WriteLn({$i fpc_timestamp});
end.

On Tue, Feb 23, 2016 at 5:57 AM, Michael Van Canneyt <

Denis Kozlov wrote

Can someone apply the patch for adding %DATETIME%, if there are no objections?

is there something wrong with what is already available??

eg:
procedure TMyApplication.DisplayVersion;
begin
   writeln;
   writeln(prog_name + {$IFDEF DEBUG} ' DEBUG' + {$ENDIF} ' version ' + prog_ver
+ ' [' + {$I %DATE%} + ' ' + {$I %TIME%} + ']');
   writeln('Compiled with FPC ' + {$I %FPCVERSION%} + ' for ' + {$I
%FPCTARGETOS%} + ' running on ' + {$I %FPCTARGETCPU%});
   writeln;
end;

Michael Van Canneyt wrote

1. The TDateTime format is not a basic format of the language. It is an agreement on how to encode date/time information in a double.

If I understand this point correctly, you are concerned about "FloatToStr(Now)" statement, where compiler is explicitly treating TDateTime as a floating point value.

This creates a problem *only* if base type of TDateTime is changed to something other than a floating point value, a record for example. Is it foreseeable that TDateTime will change its base type? In such case I presume there would be some serious breakage in RTL.

2. Some targets do not even have floats.

This feature can be IFDEF'ed.

P.S. I'm intrigued and curious about such subtleties. Forgive my ignorance if this makes no sense.

Denis

is there something wrong with what is already available??

Yes, as highlighted in my original post.

ahhh... sorry... i missed all that as it appeared similar to a signature over here...

is there a problem using sysutils' StrToDateTime() to convert to TDateTime? parsing is already done for you...

program compilerdatetime;
uses
   sysutils;
var
   formatSettings     : TFormatSettings;
   compiledatetime    : TDateTime;
   compiledatetimestr : string;
begin
   formatSettings := DefaultFormatSettings;
   formatSettings.DateSeparator   := '/';
   formatSettings.ShortDateFormat := 'yyyy/mm/dd';
   formatSettings.ShortTimeFormat := 'hh:nn:ss';
   writeln('DateTime Format : ',formatSettings.ShortDateFormat,'
',formatSettings.ShortTimeFormat);
   compiledatetimestr := {$I %DATE%} + ' ' + {$I %TIME%};
   writeln('raw string      : ',compiledatetimestr);
   compiledatetime := StrToDateTime(compiledatetimestr,formatSettings);
   writeln('TDateTime       : ',compiledatetime);
   writeln('converted to str: ',DateTimeToStr(compiledatetime,formatSettings));
end.

TBH: i see and understand why this might be a good idea but i also see and understand why it is not desirable... for me, though, there are many times that i hex browse binaries to find such compiled on strings... using a floating point number for them doesn't allow such ease of finding this data... we won't mention the additional conversion needed to print it when the current method building with %DATE% and %TIME% are already strings... but of course there is the same need to convert to TDateTime if one wants to ""time bomb"" their binary so that it doesn't work after some period of time (eg: expiring beta, limited time evaluation, simple aging out of old versions)...

2) Atomic access to build date/time. Use of {$I %DATE%} and {$I %TIME%} can have undesired effect if {$I %DATE%} is executed at 2016-01-15 23:59:59.999 and 1 ms later {$I %TIME%} is executed at 2016-01-16 00:00:00.000. Resulting combination of two directive is 2016-01-15 00:00:00, a day out of date.

i recognize this race-type condition but it really won't come up that often to be bothersome, will it?

3) Search and replace of build date/time is no longer a trivial text editor operation.

i haven't used that method in years... definitely not since i figured out how to embed them in TP6 code ;)

What if we define %TIMESTAMP% or %UNIXTIMESTAMP%, instead of %DATETIME%?

* %UNIXTIMESTAMP% - as a well defined Unix timestamp (i.e. number of seconds since Unix Epoch).
* %TIMESTAMP% - as an Int64 version of TTimeStamp (i.e. number of MSecs since 1/1/0001).

These could be inserted as plain old integers by the compiler, just like %LINENUM%, so there is no ambiguity nor implication of an agreement for encoding TDateTime as Double.

Sample code is attached. It demonstrates how to get both of these timestamps in complier with only a single dependency on SysUtils unit.

Any thoughts?

Denis

If something is platform-specific, it generally does not belong as a language extension.

Jonas

Jonas Maebe wrote

If something is platform-specific, it generally does not belong as a language extension.

It's the same as existing %DATE% and %TIME%, plus few mathematical operations, no extra dependencies.

// Existing function used for %DATE% in globals.pas:
function getdatestr:string;
var
   st: TSystemTime;
begin
   GetLocalTime(st);
   getdatestr:=L0(st.Year)+'/'+L0(st.Month)+'/'+L0(st.Day);
end;
// Proposed function for %TIMESTAMP%
function GetTimestampStr: String;
begin
   GetTimestampStr :=
IntToStr(Round(TimeStampToMSecs(DateTimeToTimeStamp(Now))));
end;

Denis

I meant platform-specific concepts (such as how to represent a date-time value in a non-textual way), not platform-specific code.

Jonas

That is what I also meant with my initial reply.

Michael.