Watch, Follow, &
Connect with Us
Public Report
Report From: Delphi-BCB/RTL/Delphi/Date - Time    [ Add a report in this area ]  
Report #:  52292   Status: Closed
DateTimeToString thread-safety issue
Project:  Delphi Build #:  10.0.2288.42451
Version:    10.0 Submitted By:   James Pujals
Report Type:  Minor failure / Design problem Date Reported:  9/20/2007 7:51:51 AM
Severity:    Infrequently encountered problem Last Updated: 3/20/2012 2:24:39 AM
Platform:    All platforms Internal Tracking #:   255659
Resolution: Fixed (Resolution Comments) Resolved in Build: : 15.0.3573.25335
Duplicate of:  None
Voting and Rating
Overall Rating: (1 Total Rating)
5.00 out of 5
Total Votes: None
Description
The second (thread-safe) overload of the SysUtils.DateTimeToString() procedure has a slight issue:  It mistakenly accesses the global variables instead of the FormatSettings field when processing the date/time separators.

The offending part is in lines 12671-12677:

          '/':
            if DateSeparator <> #0 then
              AppendChars(@FormatSettings.DateSeparator, 1);
          ':':
            if TimeSeparator <> #0 then
              AppendChars(@FormatSettings.TimeSeparator, 1);
          '''', '"':

The DateSeparator and TimeSeparator global variables are checked, instead of the fields from FormatSettings, which makes little sense.  These should be instead:

          '/':
            if FormatSettings.DateSeparator <> #0 then
              AppendChars(@FormatSettings.DateSeparator, 1);
          ':':
            if FormatSettings.TimeSeparator <> #0 then
              AppendChars(@FormatSettings.TimeSeparator, 1);
          '''', '"':

This not only will cause the separators to be left out in the unlikely chance that the local machine has them null, but in accessing the global variables it undermines the purported thread-safety of the routine.

Also, it fails to protect the code from null separator fields in FormatSettings record, which may cause unintended results.

    -dZ.
Steps to Reproduce:
None
Workarounds
None
Attachment
None
Comments

None

Server Response from: ETNACODE01