arrow-py / arrow-py/arrow

Arrow should consider using `dateutil.tz.win.tzwinlocal` on Windows.

Open
#374 4 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Python
Stars
9.1k
Forks
784
PR merge metrics
No merged PRs in 30d

Description

`dateutil` exposes two "local time" functions - `tzlocal()` and `tzwinlocal()`. In most cases, this is perfectly acceptable because `tzlocal()` uses the `time` module to query to operating system about the local time zone in an OS-independent way so the results will be the same between them. However, there is a [bug in Python / Microsoft CRT](https://bugs.python.org/issue17627) which makes it so that `time`'s time zone information is not re-loaded during the runtime of the Python operation. As such, changes in the system time zone during an application's run will not be reflected in `tzlocal()` on Windows.

Since `dateutil.tz.win.tzwinlocal()` is implemented using system calls to Windows functions, it is unaffected by this issue. It might be a good idea to have arrow try to import `tzwinlocal()` and on `ImportError` import `tzlocal()` instead. Some "time zone switching" context helpers are defined [in `dateutil`'s test suite](https://github.com/dateutil/dateutil/blob/master/dateutil/test/_common.py) that would allow you to write a [test like this one](https://github.com/dateutil/dateutil/blob/master/dateutil/test/test_tz.py#L1752) for `arrow` objects:

```python
def testTzwinLocalEquality(self):
tw_est = tz.tzwin('Eastern Standard Time')
tw_pst = tz.tzwin('Pacific Standard Time')

with TZWinContext('Eastern Standard Time'):
twl1 = tz.tzwinlocal()
twl2 = tz.tzwinlocal()

self.assertEqual(twl1, twl2)
self.assertEqual(twl1, tw_est)
self.assertNotEqual(twl1, tw_pst)

with TZWinContext('Pacific Standard Time'):
twl1 = tz.tzwinlocal()
twl2 = tz.tzwinlocal()
tw = tz.tzwin('Pacific Standard Time')

self.assertEqual(twl1, twl2)
self.assertEqual(twl1, tw)
self.assertEqual(twl1, tw_pst)
self.assertNotEqual(twl1, tw_est)
```

Obviously that's testing something else, but you can see the point - switch to two different contexts and make sure you get different answers.

Contributor guide

No contributing guide indexed for this repository

Research direction

Locate Arrow's current use of dateutil's local-time handling, then compare dateutil/test/_common.py and dateutil/test/test_tz.py around the referenced test. Verify behavior under two Windows time-zone contexts and confirm a non-Windows fallback remains available; done means local-zone changes during runtime are reflected by Arrow objects.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.