Hello, I’ve set up a solution that processes dates, and chronolog with a timestamp in nanoseconds and its reverse.
it can be used with SQL
In depth testing, there are problems,
only dates with timestamp are correct.
I’ve reviewed the code, as the weeks (52, 53) are very complex.
I’ll set it up once I’ve tested it thoroughly.
In addition, the formulas inherited from “C” need to be reworked; I’ve had some surprises.
Nice to see more people doing datetime things in Zig 
As someone who has spent quite some time with this stuff, here’s one piece of advice: IIUC, your timezones are hard-coded (zig_datetime/libdate/datetime/timezones.zig at master · AS400JPLPC/zig_datetime · GitHub), correct?
While it is fine to hard-code UTC offsets or UTC itself, this won’t work for timezones. Timezones ≠ UTC offsets. Timezones are rules that specify offset from UTC for a given date/time + geolocation. They are subject to political decisions and change over time, sometimes without much warning. This is why IANA manages the timezone database; to my knowledge this is the most widely adopted reference.
UTC time zones don’t change much, except that it doesn’t take into account summer or winter time zones. to be a purist.
vendredi à 22:43 à Coordinated Universal Time correspond à
vendredi à 23:43 dans le fuseau horaire Paris (UTC+1) winter
samedi à 0:43 dans le fuseau horaire Paris (UTC+2) summer
In the timezone quotation, there should be 2 timezones, in order to solve certain problems,
the timezone doesn’t change much for Western countries or Asia Japan China South Korea Australia.
After all that, it’s a draft and free open-source.
We could very well have a JSON file that would be more malleable, and have a program that would make it possible to update, but that’s when I’ll have worked out how to solve the week problem. I started from an interesting source …
For context, while I dare to roll my own datetime (in case you need some inspiration), I never thought about rolling my own timezones ^^
For a minimalist implementation I would probably go UTC-only, no timezones at all. So far I don’t see a sane middle ground there.
Je viens de terminer la récupération du time-zone
je vais le mettre dans un SQLite , la procédure pourra pour la mise à jour être mise dans cron.
I’ve just finished recovering the time-zone
I’m going to put it in a SQLite, the procedure for the update can be put in cron
I’ve just taken over the “timezone” concept and used “timedatectl” to make it dynamic, and I’ve also solved the problem of the start and end of the year for week 53 etc.
I’ve taken the “timezone” model and made it dynamic.