Fix UPS and USPS time parsing - #35
Conversation
|
I have tried to implement this thing on my usps tracking site at Usps tracking , but almost all of trackers not working except usps , Canada post. Ups partially work. India post, fedex kind of not working. |
|
@aldin-alagic I owe you an apology — this sat here for three years and both bugs were real. While rewriting the library in #42 I ran the old and new versions side by side over every recorded fixture to make sure nothing changed behaviour. The UPS bug slipped straight through that check, because both versions were wrong in exactly the same way. I only found it when I came back to this PR. So your report caught something my own testing couldn't. For anyone reading later, the UPS one is worse than it sounds: UPS returns I've put both fixes up as #43. I couldn't merge this PR directly — v3 moved the sources from I also added a regression test for each. The suite had a check that timestamps parse, but a twelve-hour error passes that cleanly, so it needed asserting the actual hour. Closing in favour of #43. Thanks for the fix, and sorry it took this long to act on it. |
UPS reports a 12-hour clock as "10:53 P.M.", but the format string read it as `HH:mm`, so the meridiem was ignored and every afternoon event landed twelve hours early. Seven of the twelve activities in the recorded fixture are P.M., so this was wrong far more often than not. dayjs only matches "PM", not "P.M.", so the periods have to be stripped before parsing with `h:mm A`. USPS gets the same treatment for whitespace: runs of spaces inside the date cell are collapsed before parsing, and the format list now also accepts a space after the second comma. Both were reported in #35 by @aldin-alagic in 2022. That PR targeted the old `lib/` tree and could no longer be merged after the v3 rewrite, so the fixes are reapplied here with a regression test for each — the existing sweep only checked that a timestamp parsed, not that it landed on the right hour.
3 participants
Bug fixes: