Currently, date values are stored as serialized strings.
This has a few disadvantages:
Off-by-one errors are not insignificant (error of 24h)
Events occur only in one timezone at the "correct" time (Midnight in Frankfurt is not midnight in other parts of the world)
(Parsing date strings may fail, if different formats are used)
To mitigate this, we should switch to using unix timestamps instead.
Things this approach would not solve:
A deadline that is set for midnight in Europe would still be at a different time of day in other parts of the world
(However this is also not desired behavior, because it would give more or less time depending on the location of the user. Instead, we should allow for higher precision accurate to at least one hour)
â This is merely a suggestion that has pros and cons. Feel free to discuss đ¤đŹ
Steps
[ ] Date/time variables are stored as unix timestamps
[ ] Business logic evaluates and compares unix timestamps
Currently, date values are stored as serialized strings.
This has a few disadvantages:
To mitigate this, we should switch to using unix timestamps instead. Things this approach would not solve:
(However this is also not desired behavior, because it would give more or less time depending on the location of the user. Instead, we should allow for higher precision accurate to at least one hour)
â This is merely a suggestion that has pros and cons. Feel free to discuss đ¤đŹ
Steps