You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's a mixing of dates in the code and test suite between "local" and "UTC" dates, which is probably fine if you're east of Greenwich, and which causes errors if you're not.
This command will give passing tests:
TZ=Europe/Paris npm test
This command will give failing tests:
TZ=America/New_York npm test
I think the proper handling should be to use the user's local timezone for all dates, since that's what people probably mean when they set a date in their todo.txt file.
It might be nice to add a way for parse(), stringify() and item() to take a separate timezone argument, so if you're doing development where the user's timezone isn't the same as the system timezone (say, for a Web application), you can pass the user's timezone in. I'll add that as another issue.
The text was updated successfully, but these errors were encountered:
evanp
added a commit
to evanp/todotxt
that referenced
this issue
Mar 21, 2018
There's a mixing of dates in the code and test suite between "local" and "UTC" dates, which is probably fine if you're east of Greenwich, and which causes errors if you're not.
This command will give passing tests:
TZ=Europe/Paris npm test
This command will give failing tests:
TZ=America/New_York npm test
I think the proper handling should be to use the user's local timezone for all dates, since that's what people probably mean when they set a date in their todo.txt file.
It might be nice to add a way for
parse()
,stringify()
anditem()
to take a separate timezone argument, so if you're doing development where the user's timezone isn't the same as the system timezone (say, for a Web application), you can pass the user's timezone in. I'll add that as another issue.The text was updated successfully, but these errors were encountered: