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

[pganssle]

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 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 that would allow you to write a test like this one for arrow objects:

   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.

[andrewelkins]

Interesting. Makes sense to me, unfortunately I don't have a windows machine to develop on. I'd be willing to accept a PR that addresses this.

[pganssle]

@andrewelkins Yeah, I also don't have a Windows box. For testing Windows I usually just run Windows in a VirtualBox, but it might be a good idea to add Appveyor into the CI suite for testing on Windows. For a simple change like this, and in a pinch, you can sorta just make a PR and test your Windows project in Appveyor.

[andrewelkins]

That's a good idea. If I have time I may go that route.

[systemcatch]

ref #487

If anyone feels like reviving the above PR feel free.