Attila Kovacs

Not really. I can't modify the DAC source, neither do I want to. 😕

or just scanning for both

https://learn.microsoft.com/en-us/sql/t-sql/data-types/time-transact-sql?view=sql-server-ver16#supported-string-literal-formats-for-time ISO 8601 hh:mm[:ss][.fractional seconds] It seems that Microsoft did not fully comply with the ISO 8601 standard, which allows for either a dot or a comma as the fractional seconds separator, as seen in RFC 3339. This has resulted in issues with the DAC, and simply changing the decimal separator will not resolve the problem. Microsoft's SQL Server consistently uses a dot as the fractional seconds separator. But using a hardcoded dot as the fractional seconds separator in the time format could cause issues when integrating with other sources that use a comma. Therefore, the best solution may be to introduce a new separator specifically for the time fraction, which can be left open or limited to either comma or dot. So we are there where we started.

@Uwe Raabe I found that in RFC3339, this separator it's called "time-fraction" and restricted to comma or dot. However, we do not have here an RFC3339 implementation as we can set anything to decimalseparator. The question is, is it necessary to separate the two or not. If not, it should be decimalseparator for both directions, indeed. However, I'm still not comfortable with combining the two and it gives less freedom.

So what? There is no ms separator in the "operating system" and you will define it as a dot? Who gives you the right to do so?

/ Displays the date separator character given by the DateSeparator global variable. : Displays the time separator character given by the TimeSeparator global variable. Great! Let's keep the pattern! . Displays the proposed separator character given by the ProposedSeparator global variable. Why would you restrict it for . or decimalseparator? I just can't get it, why would you prefer a hardcoded version (which would be implemented in the same way by the way) by your flavour against an universal version. All the other separators can have any value, even an emoji. What makes this ms separator so unique that we are spending hours to discuss it?

It doesn't matter what it's containing by default, righ now. If you can set it for *ToStr then you have to be able to set it to StrTo* too. And for this reason are the other separators there. There is no string magic needed to try to figure out what would be the time separator in the format string and change it to the decimal searator. Nonsense. It's not even mandatory to look both the same. Without a setting for that separator it's just a mess. Format strings are used for *ToStr and DateSeparator/TimeSpearator/Proposed are used for StrToI*. Why even do we debate over this? It's clear as day. Are you both bored?

Very funny. What about LongTimeFormat then?

I'm not parsng anything. Where did you get the information that I'm parsing anything? Could you cite it please?

Done. Thank you Uwe.

With FormatSettings.LongTimeFormat I can set anything I want, like 'hh:mm:ss,zzz'. Where did you see the hardcoded dot?

No it's not true. It's in the DAC and it fetches with point and converts with decimalseparator. I don't know who to blame, but it's obvious that it would be easy to solve with an extra field in the formatsettings. Thank you. Now you understand my question slowly. Before I'm reporting this, I wanted to ask if it's still the same because I'm also bored reporting things doesn't exists anymore.

So you mean it should be "08:00:00,00000000" in a german environment? And what about a mixed environment? Where I'm getting the values with "." from the database and I do not want to change the decimalseparator of the application?

The AI search engine for developers. https://www.phind.com/

Wow, well, a shitty design.

Use it as TStringHelper.IsNullOrWhiteSpace() in order to avoid misunderstandings. Your examples are just the side effects of this record helper on the string type.

As we have learned from other highly qualified individuals, VCL has not been abandoned; rather, it was completed a long time ago.

https://github.com/rj1/chatgpt-irc you could try to create a private room with 2+ bots

are you gonna start replying on 2 years old comments? could you please leave me out of this?

In short, one of the must haves.

The problem is that you don't even realize whether a human or an AI is serving you, and we will rely on them for more and more decision making.

That's what I was talking about. AI won't kill us in the way you have seen it in the television. It will kill us with wrong answers.

None. It's a language robot. The content is always made up, even if it's accidentally true. I asked to show me the implementation of TListDataSet and it was like ListDataSet: TClientDataSet;

http://www.x-files.pl/components/xdbdata.html

I believe he has a good understanding of the topic, he just needs some additional ideas to consider.