Closed cltrudeau closed 2 years ago
That's surprising. It would appear that Linux and MacOS use a different base time for their timestamps. These aren't important differences and are going to be tricky to solve in a cross-platform way. You can check by running:
from datetime import date date.fromtimestamp(0)
On my Linux box that returns datetime.date(1970, 1, 1)
. If MacOS returns something different, I suggest that we just skip the tests on MacOS platforms.
I've been digging a bit, and it appears that macOS returns the epoch in the local time zone. This problem isn't just mac, but mac west of UTC. This can be fixed with a variable in the test setup. I'll include it in the coming PR.
Thanks for digging into that!
Yeah, well it was bugging me. I maintain a library on converting epochs and milli-epochs back and forth and I couldn't understand why macOS appeared to be returning a negative epoch value -- nothing comes before Jan 1, 1970 in the Unix world :)
Any reason you didn't include this in that last PR?
I had a PR that fixed this and something else but accidentally did it on my master branch. Looks like when I cleaned up the commit and put it on a feature branch it killed the PR without me realizing. I'll open another one from the feature branch.
Fixed by the above PR.
Describe the bug Hi Peter,
We chatted in the lobby a couple of months back and I finally got some time to attempt a fork for an MR. Before making changes I ran the tests and am getting three errors, all FileBrowser widget -- it appears to have something to do about a date assumption.
To Reproduce Run "nosetests" on a macos. Attempted with both FORCE_TTY on and off, fails in both cases
Expected behavior Unit tests pass
Screenshots Test output appended at end of ticket
System details (please complete the following information):
Additional context