-
Notifications
You must be signed in to change notification settings - Fork 8
Description
This has come up multiple times over the years (#176, #276) and v3 is probably a great time to finally make the call.
The internal calls on the input Date in apdate assume the locale the code is running in — this means there are windows of time where you may end up with the wrong day because in a user's timezone the day has not turned over yet or already changed.
What makes this so tricky is journalize has absolutely no say in the origin of the Date it gets passed. Is it timezone adjusted? Was it just built from an ISO string?
The only observation I can confidently make — I've foisted journalize into so many codebases and I cannot think of a single time I've intentionally passed in a timezone aware date. I'd say nearly all scenarios where I've used it the original source was an ISO string I turned into a Date either via date.split('-') (and so on) or with a parse method via something like date-fns.
My hunch is I'm not alone in this.