Fix timezone-dependent getDate timestamp test

[MohammedAlkindi]

Symptom

pytest on a clean clone fails for any contributor whose machine is east of UTC+3:58 — Dubai, India, China, Japan, most of Australia:

FAILED tests/test_tablib_dbfpy_packages_utils.py::UtilsGetDateTestCase::test_getDate_datetime_timestamp
AssertionError: datetime.date(2019, 10, 20) != datetime.date(2019, 10, 19)

CI never sees it because hosted runners run in UTC, and the full-matrix Windows/macOS/Linux jobs all share that timezone.

Mechanism

getDate converts a number with datetime.fromtimestamp(), which uses the local timezone — that is its documented contract ("assuming it's a timestamp"). The test's timestamp 1571515306 is 2019-10-19 20:01:46 UTC, so anywhere with an offset of +3:59 or more the local date is already October 20. The hardcoded dt.date(2019, 10, 19) therefore encodes "a timezone west of UTC+4", not the function's behaviour.

Fix

Assert the documented contract instead of one timezone's rendering of it:

self.assertEqual(output, dt.date.fromtimestamp(value))

The sibling test_getDateTime_datetime_timestamp already avoids this by asserting only the type.

What is deliberately unchanged

getDate itself. Local-time interpretation is the vendored dbfpy's long-standing semantics, and changing it would alter written DBF dates for existing users — that would be a behaviour change, not a test fix.

Evidence

Reproduced on Windows 11 in UTC+4: before, 1 failed, 182 passed on a clean clone at c8ff4e1; after, 183 passed. Also green with TZ=UTC and TZ=America/Los_Angeles — though I'd weight the real-machine result over those, since TZ handling on Windows Python is not a full timezone simulation.

Added myself to AUTHORS per the contributing guide.