Repository navigation
Implicit conversions from/to string should be strictly using invariant locale #1271
Description
Go through the codebase and validate/fix.
Relates to #1173.
{{ message }}
Go through the codebase and validate/fix.
Relates to #1173.
Activity
deAtog commentedon May 21, 2026
I don't think using the InvariantCulture is sufficient. To be compliant with the FirebirdSql server, any conversions should match those in https://github.com/FirebirdSQL/firebird/blob/4dd80eda5d4bf1f41c15fa4795567896b06da39e/src/common/cvt.cpp
For example, calling DateTime.ToString with the InvariantCulture will output a string in "MM/dd/yyyy HH:mm:ss" instead of the expected "yyyy-MM-dd HH:mm:ss.ffff" ISO format.
cincuranet commentedon May 21, 2026
There's nothing like "compliant with server".
deAtog commentedon May 21, 2026
@cincuranet Sure there is. You should be able to perform a CAST on the value stored without it failing. Any conversions should match whatever CAST does.
cincuranet commentedon May 21, 2026
That's your assumption.
deAtog commentedon May 21, 2026
No, that is the expected behavior. The following two statements should store the same value in the database when
@datetime_valueis a DateTime object.The only difference between these two statements is that the first does an implicit cast, while the second does an explicit one. The latter statement works as expected, the former one currently does not.
cincuranet commentedon May 21, 2026
That builds on the assumption that storing typed data in strings/varchar is correct. It is not. And as I said in the issue, you'll get all sorts of issues. Focusing on that is waste of time.
deAtog commentedon May 22, 2026
It is not a waste of time to expect the client to store data consistently and in the same form that the server would. There should be no difference in the value stored in the above statements regardless of the destination field type. Storing data in a consistent manner ensures interoperability across libraries and with built-in functionality of the server.
cincuranet commentedon May 22, 2026
You just described data types.
deAtog commentedon May 22, 2026
@cincuranet Sure, but there are many data types. There are client data types and server data types. The client should only need to know how to convert client types to the closest matching server type that preserves the original value when sending values to the server. For example always using a timestamp server type to represent a client DateTime type, and always using a double server type to represent a client double type. When retrieving data from the server, the client should only need to know how to convert the server type to the requested client type. For example if the server returns an Int64 and the client is expecting a Double, the client should know how to do that conversion. The current implementation of FbDataReader is broken in this regard.
I tested what would happen if I replaced the parameter field descriptor returned from preparing a statement with one generated on the client for a DateTime object represented by a timestamp. Where it worked, the values in the database from the two statements above were identical. It only failed for the embedded FirebirdSql implementation which I didn't really bother to investigate further due to my very crude implementation.