DateTime.MaxValue of DotNet returns null when using with strftime
(1) By anonymous on 2025-01-10 13:36:37 [link] [source]
When using DateTime.MaxValue from DotNet with strftime('%Y','9999-12-31T23:59:59.9999999') I get a null value returned.
After doing some analysis, I think it is due to the high precision of the second. If I manually enter only 3 numbers instead of the 7 last numbers, I get the expected result of '9999'. With the 7 digits precision I am probably over the max allowed value, which is why I get the null value.
Somehow this worked correctly up to and including version 1.0.116. Since then I can no longer use DateTime.MaxValue.
As I have not seen a change in the release notes, does anyone know anything about this problem?
(2) By anonymous on 2025-01-10 15:08:54 in reply to 1 [link] [source]
Edit: Since I forgot to mention it, resp. saw too late that this is a general forum, I'm using the System.Data.Sqlite library.
(3.1) By Aask (AAsk1902) on 2025-01-10 17:26:46 edited from 3.0 in reply to 1 [link] [source]
SQLite time values recognises 3 digits for milliseconds when specified. C# DateTime.MaxValue does not return milliseconds.
(4) By anonymous on 2025-01-13 07:18:34 in reply to 3.1 [link] [source]
Thanks for your reply.
Exactly, but somehow it was handled until version 1.0.116 even when DateTime.MaxValue supplied more than 3 digits. And I wasn't able to see a change in this area in the release notes.
(5) By anonymous on 2025-01-13 11:08:10 in reply to 3.1 [link] [source]
From the cited page:
Exactly three digits are shown in the examples because only the first three digits are significant to the result, but the input string can have fewer or more than three digits and the date/time functions will still operate correctly.
(6.4) By Aask (AAsk1902) on 2025-01-13 15:05:07 edited from 6.3 in reply to 5 [source]
SQLite & System.Data.SQLite
System.Data.SQLite version 1.0.116.0 used SQLite 3.38.5
System.Data.SQLite version 1.0.117.0 used SQLite 3.40.0
System.Data.SQLite version 1.0.118.0 used SQLite 3.42.0
System.Data.SQLite version 1.0.119.0 used SQLite 3.46.1
`
The change in behaviour relates to SQLite version 3.40.1:
sqlite> select sqlite_version() as version,strftime('%Y','9999-12-31T23:59:59.9999999')as year;
version year
------- ----
3.38.5 9999
sqlite> select sqlite_version() as version,strftime('%Y','9999-12-31T23:59:59.9999999')as year;
version year
------- ----
3.39.4 9999
sqlite> select sqlite_version() as version,strftime('%Y','9999-12-31T23:59:59.9999999')as year;
version year
------- ----
3.40.1
NOTE:
- Neither the release note(s) for 3.40.0 dated 2022-11-16 nor that for 3.40.1 dated 2022-12-28 mention any changes to strftime.
There have been 21 releases since version 3.38.5 corresponding to System.Data.SQLite version 1.0.116.0. The break you experience relates to SQLite rather than System.Data.SQLite. In the interest of backward compatibility, I do not believe any retrospective change to strftime is likely or viable.
I believe the best option is to manage a workaround in your code.
The documentation text that you refer to is out of sync: that is a matter that probably needs to be addressed.
In time, it would be interesting to see whether the documentation is brought into line with the code or the code is brought into line with the documentation.
(8) By anonymous on 2025-01-14 08:02:13 in reply to 6.4 [link] [source]
I see, many thanks. I probably have to do a workaround
(7) By mistachkin on 2025-01-13 23:23:13 in reply to 1 [link] [source]
Do you have a quick snippet of code that demonstrates the problem?
(9) By anonymous on 2025-01-14 08:08:08 in reply to 7 [link] [source]
A quick snippet would be
strftime('%Y','9999-12-31T23:59:59.9999999')