LongDateFormat, ShortDateFormat deprecated

[hakelm]

I see that LongDateFormat and ShortDateFormat (and more in sysinth.inc) are deprecated.
What am I supposed to use instead?
Thanks in advance for any tip
H

[marcov]

This is delphi compatible, the variables still exist, but are now bundled in a record called "formatsettings"

So prefix the constants with "formatsettings." and it will be ok

[hakelm]

Thanks
H

[Remy Lebeau]

This is delphi compatible, the variables still exist, but are now bundled in a record called "formatsettings"

So prefix the constants with "formatsettings." and it will be ok

Note that in Delphi, the individual global formatting variables were finally removed in XE3, so you have to use the global FormatSettings record instead.  Sounds like FreePascal has not caught up with that change yet.  But if you need to customize format settings for any given formatting function, you should be using the overloaded version of that function that accepts a TFormatSettings variable as input.  Don't rely on globals at all.  They are not thread-safe, which is why they were deprecated (and removed) to begin with.

[hakelm]

For me one problem remains, we have no inverse to FormatDateTime i.e. any function like StrToDateTime(const FormatStr: string;
  DateTime: string):tdatetime;
H

[molly]

For me one problem remains, we have no inverse to FormatDateTime i.e. any function like StrToDateTime(const FormatStr: string;
  DateTime: string):tdatetime;
H

Unless i'm completely misinterpreting what you wrote, yes we have.

You should be looking for the second version.

You can either change the default tformatsettings or define your own.

[marcov]

Cough, from http://www.freepascal.org/docs-html/rtl/dateutils/scandatetime.html :

"In effect, this function does the opposite of what FormatDateTime does"

[hakelm]

My fingers slipped, sorry about that. I meant datetimetostr.
Now executing

   writeln('now: ',(now),' default: ',datetimetostr(now));
   myformatsettings.ShortDateFormat:='yyyy-mm-dd hh:nn:ss';
   writeln('now: ',(now),' myformatsettings.ShortDateFormat ',myformatsettings.ShortDateFormat,' ',datetimetostr(now,myformatsettings));


now:  4.2692421830104169E+004 default: 18-11-16 10:07:26
now:  4.2692421830104169E+004 myformatsettings.ShortDateFormat yyyy-mm-dd hh:nn:ss 2016-11-18 10

which isn't exactly what I wanted.
H

[marcov]

Note that in Delphi, the individual global formatting variables were finally removed in XE3, so you have to use the global FormatSettings record instead.  Sounds like FreePascal has not caught up with that change yet. 

Removal is not needed for compatibility. We have no D7 user base to pester to upgrade :-)

But if you need to customize format settings for any given formatting function, you should be using the overloaded version of that function that accepts a TFormatSettings variable as input.  Don't rely on globals at all.  They are not thread-safe, which is why they were deprecated (and removed) to begin with.

The global record is as thread unsafe as the individual values. So if you remove something, you need to remove/deprecate  formatsettings and the non TFormatsettings functions too. This is also why I see no point in removing the individual values, and deprecating it all is a bit too harsh IMHO

Note that FPC  had a record for this (but called defaultformatsettings) since before 2000, pretty much the first thing done with it after proper "absolute" support. This is also still supported.

[molly]

@marcov: oops 

Thank for the correction

which isn't exactly what I wanted.

Now, i am completely puzzled 

Before you do anything else to your MyFormatSettings do:

Code: [Select]

MyFormatSettings := DefaultFormatSettings;
And then try your code again.

But... isn't it easier to just use FormatDateTime ?

Code: [Select]

  S := DefaultFormatSettings.LongDateFormat;
  writeln('now: ',(now),' DateFormat ', s, ' ', FormatDateTime(s, now));

  S := 'yyyy-mm-dd hh:nn:ss';
  writeln('now: ',(now),' DateFormat ', s, ' ', FormatDateTime(s, now));


edit:
actually. for your example to work it should read like this:

Code: [Select]

  MyFormatSettings.LongDateFormat:='yyyy-mm-dd hh:nn:ss';
  MyFormatSettings.DateSeparator := '-';
  MyFormatSettings.TimeSeparator := ':';
  writeln('now: ',(now),' myformatsettings.LongDateFormat ',myformatsettings.LongDateFormat,' ',datetimetostr(now,myformatsettings));


[Graeme]

But if you need to customize format settings for any given formatting function, you should be using the overloaded version of that function that accepts a TFormatSettings variable as input.  Don't rely on globals at all.  They are not thread-safe, which is why they were deprecated (and removed) to begin with.

That last statement is wishful thinking. The Free Pascal RTL is not thread-safe!  eg: Take a  look at the implementation of FormatDateTime() that takes a TFormatSettings parameter. In turn, it calls DateTimeToString(). Nowhere in that implementation is there any thread-safe code. I double checked even against FPC 3.1.1 (trunk).

Delphi's implementation might be different - I don't know as I don't look at Delphi code at all.  If you do know for sure that Delphi's TFormatSettings functions are thread-safe, then please report it as missing Delphi compatibility on FPC's Mantis bug tracker.

[marcov]

In turn, it calls DateTimeToString(). Nowhere in that implementation is there any thread-safe code.

Let's turn that around, what constructs in DateTimetoString are not threadsafe ?

[Thaddy]

@Graeme
It is the use of the TFormatSettings record that makes the underlying routines thread safe, because every thread should obtain its own copy of TFormatSettings.
It has nothing to do with DateTimeToStr() as such, but with thread issues that could occur in the old situation where formatting fields could be written to from multiple threads. That is what makes the old situation not thread safe and the new situation thread safe,
It the new situation the format settings should be taken from a thread local copy of TFormatSettings. Then and only then all formatting function are thread safe.
Note that that is still the responsibility of the programmer. The global var FormatSettings is of course not thread safe. You *must* use a local copy.
This is the way that Delphi documents it by the way

See http://docwiki.embarcadero.com/Libraries/Seattle/en/System.SysUtils.TFormatSettings

And in FreePascal it is exactly the same. I have no clue how you came to the conclusion that FPC should differ from Delphi in this regard.
That is simply a false assumption. See also: http://www.freepascal.org/docs-html/rtl/sysutils/datetimetostr.html second overload.
Of course it is a bug if the first overload is used, I have to check that.

edit: I did. You are talking nonsense, it calls the threadsafe version, QED:

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

1. // from dati.inc
2. function FormatDateTime(const FormatStr: string; DateTime: TDateTime; const FormatSettings: TFormatSettings; Options : TFormatDateTimeOptions = []): string;
3. begin
4.   DateTimeToString(Result, FormatStr, DateTime, FormatSettings,Options);
5. end;
6.  

[Graeme]

The global var FormatSettings is of course not thread safe.

This is what I meant. Multiple threads could change the values of the global FormatSettings variable at will. What counts in its favour is that it is just a simple record structure, so it doesn't have any knock-on effect (eg:  setter methods in a Class structure that could trigger other calculations).

This time round I took a closer look, and indeed the TFormatSettings record is passed as a const to all relevant functions in the RTL, so yes you are right - in effect each RTL function or procedure gets its own copy that can't be modified. So I guess the risk is minimal all round.

[Thaddy]

Not only that - passed as const, but you are actually supposed to create a TFormatSettings variable yourself per thread and call getformatsettings or one of the platform specific getxxxformatsettings to populate it. After that you can set it up as necessary.
And use only formatting functions with the TFormatSettings parameter. That way it is really guaranteed to be threadsafe.
The global formatsettings variable is definitely NOT threadsafe by itself.
Because const for a record parameter means you can not change the record instance itself, but you can change its members!

This is in the Delphi documentation I pointed to and I suppose this is also in the trunk documentation.
Later Delphi versions have more options and FPC lags atm. behind with the record structure. But the principle is exactly the same.