In the control panel, use "Region and Language" to set the format to "German (Germany)". Then run the Unbound demo, and observe the date displayed in the header: it says "Sonntag, 17/ Juli", but correct is "Sonntag, 17. Juli" (PERIOD instead of the SLASH).
Screen shots attached.
We have closed this ticket because another page addresses its subject:
TFormatSettings.TranslateDateFormat returns an incorrect result with Delphi XEDateseparator incorrect if date format is German
Answers
Hello,
After further investigation, we found that this issue relates to an issue in the Embarcadero Delphi IDE.
For more information, please review the B203525("TFormatSettings.TranslateDateFormat returns an incorrect result with Delphi XE") report.
Thanks,
Valdemar
Comments
(3)
ES
9 years ago
The Problem is still present with DevExpress VCL v14.x controls under Delphi XE7:
Calling TcxSchedulerDateTimeHelper.DayToStr(now, 0, false) gives 'Freitag, 13/ November' on a German language system
while DateToLongDateStr(now) gives correctly 'Freitag, 13. November 2015'
Calling cxFormatController.UseDelphiDateTimeFormats := true; beforehand also corrupts the call to DateToLongDateStr. Both functions use cxGetDateFormat().
It seems like the date formatting functions inside cxDateUtils.pas do not replace the special character '/' in the format strings with the current user's DateSeparator.
The other linked issue B203525 is not the same problem.
ES
9 years ago
Just another remark: I tried your current Feature Demo and the dates in the Scheduler are also wrong.
Hello,
To process your recent post more efficiently, I created a separate ticket on your behalf: German dates are displayed incorrectly in Scheduler. This ticket is currently in our processing queue. Our team will address it as soon as we have any updates.
Hello Martin.
We have discussed this issue with our developers. This behavior is caused by the fact that there is no way to format the DateTime value for all locales based on the DayHeader occupied area. That is why we have implemented it in a common manner.
As a workaround, you can format this text manually using custom draw capabilities of TcxScheduler. Handle its OnCustomDrawDayHeader event as follows:
procedure TCustomDrawDemoMainForm.SchedulerCustomDrawDayHeader( Sender: TObject; ACanvas: TcxCanvas; AViewInfo: TcxSchedulerDayHeaderCellViewInfo; var ADone: Boolean); begin AViewInfo.DisplayText := DateTimeToStr(AViewInfo.DateTime); end;Another solution is to create a custom TcxSchedulerDateTimeHelper descendant, override its DayToStr method, and initialize the TcxScheduler's DateTimeHelper variable using your own class.
Hopefully, my explanation is clear.
Best regards,
Ingvar.
Ingvar,
You seem to be saying that due to the (potentially) limited space you could not be sure whether a locale-formatted date would fit, and therefore you decided to "roll your own" date format. The problem is that the format you came up with is simply incorrect in most locales, just like saying "Monday, 17: July" would be wrong in the English locale. [BTW, these incorrectly formatted dates are also all over the printouts in PS4 which is why I am so insistent.] IMHO, correctly formatted output string should take precedence over cosmetics. But I do understand the issue, and here is what I came up with:
One can get a proper formatted date for any locale by using FormatSettings.LongDateFormat. (I do not think you would want to use the ShortDateFormat since that does not contain any long day names.) However, as the name suggests dates formatted like that can be somewhat long since they contain the year (e. g. "Monday, July 18, 2011" / "Montag, 18. Juli 2011"). One could start with the LongDateFormat (for the active locale) and strip the year information out, then format the date using the remaining format string. This part is a little bit hackish, but here goes:
function FormatDateLongWithoutYear (TheDate : TDateTime) : string;
var
FormatStr : string;
begin
FormatStr := ReplaceText (FormatSettings.LongDateFormat, ''' de ''yyyy', ''); // take out year info for spanish locales
FormatStr := ReplaceText (FormatStr, ', yyyy', ''); // strip out year info if separated by a comma
FormatStr := ReplaceText (FormatStr, 'yyyy', ''); // try again in case there is no comma
DateTimeToString (result, FormatStr, TheDate);
end;
This would get most locales right and so be a huge improvement over the current situation. There might be a need for additional lines in the above code to deal with cases where the year information is part of the date format in yet a different way.
Let me know what you think,
Martin
Hello Martin.
This request sounds interesting. I am forwarding this issue to our developers for further processing. I will get back to you once we have any results or need any additional information.
Thank you for your help in making our products better.
Best regards,
Ingvar.