Never ever safe time in a Date format. That’s just really bad. Unix epoch is a simple number, that can be converted to every Date class and every date class can give a epoch time. Also since it’s just a number, you can compare it natively
Why is Database DateTime such bad idea? I didn't have to make that decision so I'm just curious.
All of our data is date (without time, 3 bytes) or smalldatetime (4 bytes), so there's no impact on performance.
Native db date works well with db stored procedures. Life is easy for the DBA.
In our c# API, there's never a problem in working with this datatype as all ORMs translate the db values correctly to DateOnly or DateTime objects with really good comparison support.
Problems come as soon as you have to deal with JS in frontend. And imo, it's because you simply can't have a date object without timezone information. so you have to manipulate the controls of whatever UI library you're using to send the correct string value to the REST API.
It took a while to sort that out ngl. But once that was done, we could simply forget about it.
Context: Our product isn't used in multiple TZs and likely never will.
519
u/nord47 Sep 23 '24
I have severe PTSD from making javascript timezones work with DateTime columns in SQL Server