Open jbalboni opened 3 years ago
I'm moving this back to icebox, because I don't think it's worth switching our timezone handling code to use date-fns until their UTC handling improves, or we decide on a different option. The issues I ran into are:
This might get easier when we're using the vaos service and all start dates are coming through the same, but even then, the lack of UTC support is frustrating and leads to more confusing code. We can write helper functions for these issues, but those are likely to be error prone and easy to forget, for very little actual value right now.
Luxon or day.js seem better suited to us, and use the same polyfill for zones as date-fns, but I'm hesitant to try to get VSP to add a third date library to vets-website.
Create additional tickets to break up work as needed
We should be able to replace uses of moment-timezone's
.tz()
helper in our application code and switch to the date-fns timezone helpers. Those helpers rely on polyfilled timezone data, so this should result in some reduction in bundle size for most users.Important:
.tz()
usage you're replacing to convert to usedate-fns
. It's ok to break off complicated pieces of this ticket into smaller ones.AC:
.tz()
are appropriately converted to usedate-fns
helpers, or a set of tickets created to accomplish this