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.
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:
This command will give failing tests:
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.