Comment by abustamam
3 days ago
I always found it weird when systems code dates as DateTime strings. There needs to be a different primitive for Date, which is inherently timezone-less, and DateTime, which does require a timezone.
After having a bunch of problems with dealing with Dates coded as DateTime, I've begun coding dates as a Date primitive, and wrote functions for calculation between dates ensuring that timezone never creeps its way into it. If there is ever a DateTime string in a Date column in the database, it's impossible to know what the date was supposed to be unless you know you normalized it at some point on the way up.
Then I found that a lot of DatePicker libraries, despite being in "DATE" picker mode, will still append a local timezone to its value. So I had to write a sanitizer for stripping out the TZ before sending up to the server.
That said, I am pretty excited about Temporal, it'll still make other things easier.
Temporal does have PlainDate, which is the Date primitive you're describing (by a different name, presumably to not collide with the old Date type).
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
This is great! Thanks for sharing
This has been a huge source of frustration in C#.
The BCL-provided DateTime was really confusing, especially when you just needed a Date. They eventually got around to including a DateOnly, but before that happened I switched to a library called "Noda" (or Joda in Java) and after a bit of a learning curve, it made everything a lot easier to reason about.
It has LocalDates and LocalDateTimes, as well as Instants to store UTC times. It also offers ZonedDateTimes, but I don't use those as much. I work in healthcare. And so many regulations involve strictly dates. Like, "You have 5 days to do X", not "You have 120 hours to do X", and as such, storing the time with a lot of this data can add more complexity.
Wow! And yeah I'd imagine Healthcare requires a bit more strictness, you can't really afford an off by one day error, or sometimes even an off by one hour error.
You're absolutely right.
The calculations themselves are usually pretty easy with a few exceptions, it's just that there are TONS of them. And they all slightly depend on each other. And they change. Often.
There needs to be a difference between an Instant, an Instant at an Observed Location, and a 'Specification for constructing a date that might or might not have already passed or pass in the future'.
E.G. in a conversation "Lets open the shop at 9am every day that it isn't closed." Is a fairly simple recurrence, with some exceptions*. If timezones change the scheduled time remains evaluated again on each day.
Yeah that's a good point, and also takes into account the dreaded DST (what are this business's operating hours for example, which remains the same locally but would change in UTC)