API is locale sensitive?

[molnarti]

I've been trying to vibecode a simple Android app that would scan the QR code we have on all the receipts and based on it save the fueling data to Lubelogger.
During this i realized, that the API is sensitive to the set regional formats. E.g. is expects dates and numbers in same format as the locale set in the app.
I am finding this behavior quite odd, especially since there is no way to query the expected format via the API (as far as i can tell).
Are there any plans to change this, and have the API locale independent? I know this change would be rather a pain in the ass, but it might have with developing external tools.

[hargata]

https://docs.lubelogger.com/Advanced/API#locale-invariant-formatting

Can also be configured in the Server Settings Configurator

[molnarti]

yes, i have also noticed there is a new way for doing that. unfortunately that is currently broken for me because of #1225 (comment) 😮‍💨

[molnarti]

but the culture-invariant issue still appears on the GET /vehicles endpoint, even after doing the configuration via the web UI

tried locale both sk and sk-SK but with the same result. there is no .env file anymore, so all config is coming from the serverConfig.json file.

[hargata]

Do you have any logs from the Docker Container?

[molnarti]

ok, i think its caused by an invalid purchase date entry in the database.

i had this error in the docker logs: System.FormatException: String '06/29/2022' was not recognized as a valid DateTime.

i have updated the purchase date and now the API works.

however i think there is still an issue in how Lubelogger writes the data into the db - it looks like its written as a string formatted by the current locale. my current entry looks like this: "PurchaseDate": "29. 06. 2022" All other records have the date saved as 2025-02-12T00:00:00
i think this will break whenever a vehicle purchase date is saved, then the locale is changed - but apparently it did not happen in your case for some reason

[hargata]

That makes sense, yeah. It's because SoldDate and PurchaseDate is stored as strings, it's the only place where dates are stored as strings because of it's nullable nature and it was a design decision made a long time ago, it shouldn't happen anymore once the date formats are fixed.