What’s the ambiguity issue with Unix time stamps? Unix time stamps are expressed as a UTC offset always so I’m not sure how time zones come into play / what parsing might involved.
And when parsing those values, you could do for example (JS) `new Date(ts*1000).getDay()`. Of course that's not correct - you need to use the UTC methods. But it's easy to miss, and may pass all your tests until you switch the timezone.
Those aren't massive issues - you just have to be careful with the parsing and serialization, and you need to be careful in any case. It just explains my personal preference.
I could see it being more convenient if you're just dumping the raw values without any transformation or you don't know what data type is stored in a column, but otherwise the difference seems largely one of taste and not so much relative error rates?
However, with a string date you can bypass the Date class completely in many use cases.
My experience with this is anecdotal, but I've ran into many bugs due to conversion between day-precision values and Date objects. One example was a date picker library that returned values at 00:00 in the local timezone instead of UTC, which were then not correctly converted to UTC-based values before being persisted.
Once again, these are all preventable issues - just use UTC everywhere. I've just seen issues like that happen enough that I prefer never converting between dates and timestamps if I can avoid it.
Oh man, that sounds ugly, and an invitation for disaster. Lots of off-by-ones.
In my project's case, I also need to do math with them for analytical purposes. It's a game collection manager, so it's tracking the day you bought, beat, and 100%d a game.
I derive how long it took to beat a game by subtracting the UNIX timestamp of the purchase date from the beaten date's timestamp, then divide by (60*60*24) to measure days. It's handy to show games in the backlog and sort by purchase date, too, so you can target the games that've been sitting the longest. There are plans to graph out a collection in terms of its path from new to beaten to completed in a Gantt-style chart or something else fun.
But yeah, I just thought to ask because in JSON I and others can read `2023-12-01`, but not `1701417600`. SQLite and Python can do conversions for the calculations, and Python even has the timedelta module that might make my comparisons easier to do or slightly more accurate.
Edit: asterisks
In the case of my project, the goal is to have UTC-only timestamps/dates, and since the resolution I'm using it for is a calendar day, time zone doesn't matter. I will still need to be explicit about it in my code when converting.
Or maybe edge cases like historical timezone changes, leap seconds?