3 ms·
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 Da
by abustamam 10mo 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.
- cpmsmith 10mo agoTemporal 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/Reference/Global_Objects/Temporal/PlainDate https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- abustamam 10mo agoThis is great! Thanks for sharing
- mjevans 10mo agoThere 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.
- abustamam 10mo agoYeah 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)
- mexicocitinluez 10mo agoThis 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.
- abustamam 10mo agoWow! 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.
- mexicocitinluez 10mo agoYou'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.