Python for Windows reports wrong local time when run under Cygwin on Europe/Moscow TZ

L A Walsh
Tue Jun 8 13:04:27 GMT 2021

On 2021/06/08 05:28, Mike Kaganski wrote:
> No, I report a problem that a native program runs incorrectly *under 
> Cygwin*, because Cygwin is indeed part of the picture.
	The problem is in the MS-Win term program.  If you report
it to them and tell them it only misbehaves when you have a 3rd
party app injecting "dll's" (libraries) into the MS-program, they
will _likely_ tell you that they can't support every 3rd party
program that injects libraries into MS programs, and they can only
support you running it without the 3rd party programs.

	Just like cygwin devs have noticed that various
other programs 
(see BLODA: )
are known for causing problems in cygwin.  The cygwin devs can't
support all the 3rd party programs that interfere.

> and being not a 
> prophet, I can't know in advance if the actual bug lies in Windows, in 
> Python, or in Cygwin interaction with them. 
	As I said before, python is probably picking up time-zone
changes from _both_ cygwin and windows.  The workaround is to use
the appropriate version of python with the correct OS.  Cygwin is
an OS emulation, Win10 is another OS.  They both have versions of
python designed for them.  If MS thought the cygwin version of python
was good enough for every purpose, they wouldn't have issued their
own version.

	You might ask on a python list if anyone else has experienced
something similar with python or any other program.  I'm fairly sure
that neither MS nor cygwin design their OS with python in mind and
that it is python that is interacting funny when running under some
merge of both.  Have you asked the python people about this problem?
What did they suggest?

> And I assume that Cygwin is 
> not declaring that its users "must never run native applications from 
> Cygwin", so I find that passage above inappropriate and off-topic.
	Just because they don't tell you to never run linux apps
directly in cygwin doesn't mean they support it if you insist on 
trying.  Most devs won't tell you all the things you can't do, because
that list is endless.  That certainly doesn't suggest that they would
support all the things that don't work.

>> Though as to why -- likely the windows version is getting time zone
>> clues + correction from BOTH cygwin and Windows, like it's told its
>> in a TZ that is at 1 time, while Windows feeds it other data that
>> says it is 2 hours off from the default. 

> Maybe. It's OK if no one here knows the reason - I of course don't 
> expect anyone here obliged to give an answer. My question was intended 
> to ask if someone (e.g., a Cygwin dev) somehow can see the problem from 
> their expertise, and - maybe - even know how to fix it. Maybe there's 
> some technique how to workaround this problem - and even if it's not a 
> Cygwin's bug, it still could be useful for Cygwin users, hence still the 
> post to the list, accompanied by someone's workaround, would be 
> reasonable and useful.
	When you say you run the Win python on cygwin, what do you
mean?  ... I just ran python from windows (not the same version you
have, but an old one python2.7.  I ran it from bash, but the resulting
python doesn't have any cygwin libraries loaded -- that tells me that python is looking at some absolute paths and the environment and picking
up both -- it's a MS-python "bug".
Look in its environment and remove any thing for timezone and try that.

Or look in your path and make sure there are no cygwin directories
in the path that your win-python is using.  I'm pretty sure that
will solve your problem.

FWIW, here is a list of what python running from 'bash.exe' from
cygwin has loaded -- and none of it is from cygwin:

/prog/Sysinternals/cmd/exe> Listdlls python

ListDLLs v3.1 - List loaded DLLs
Copyright (C) 1997-2011 Mark Russinovich
Sysinternals -

python.exe pid: 4928
Command line: C:\Python27\python.exe

Base                Size      Path
0x000000001d000000  0xa000    C:\Python27\python.exe
0x0000000077760000  0x19f000  C:\Windows\SYSTEM32\ntdll.dll
0x0000000072950000  0x3f000   C:\Windows\SYSTEM32\wow64.dll
0x00000000728f0000  0x5c000   C:\Windows\SYSTEM32\wow64win.dll
0x00000000728e0000  0x8000    C:\Windows\SYSTEM32\wow64cpu.dll
0x000000001d000000  0xa000    C:\Python27\python.exe
0x0000000077920000  0x180000  C:\Windows\SysWOW64\ntdll.dll
0x0000000076840000  0x110000  C:\Windows\syswow64\kernel32.dll
0x0000000076740000  0x47000   C:\Windows\syswow64\KERNELBASE.dll
0x000000001e000000  0x227000  C:\Windows\SysWOW64\python27.dll
0x0000000077420000  0x100000  C:\Windows\syswow64\USER32.dll
0x0000000076580000  0x90000   C:\Windows\syswow64\GDI32.dll
0x0000000076980000  0xa000    C:\Windows\syswow64\LPK.dll
0x0000000075f70000  0x9d000   C:\Windows\syswow64\USP10.dll
0x0000000076690000  0xac000   C:\Windows\syswow64\msvcrt.dll
0x0000000076790000  0xa1000   C:\Windows\syswow64\ADVAPI32.dll
0x0000000076560000  0x19000   C:\Windows\SysWOW64\sechost.dll
0x0000000077330000  0xf0000   C:\Windows\syswow64\RPCRT4.dll
0x0000000075040000  0x60000   C:\Windows\syswow64\SspiCli.dll
0x0000000075030000  0xc000    C:\Windows\syswow64\CRYPTBASE.dll
0x00000000751a0000  0xc4c000  C:\Windows\syswow64\SHELL32.dll
0x0000000075130000  0x57000   C:\Windows\syswow64\SHLWAPI.dll
0x0000000071580000  0xa3000   C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCR90.dll
0x0000000076630000  0x60000   C:\Windows\SysWOW64\IMM32.DLL
0x0000000076e00000  0xcc000   C:\Windows\syswow64\MSCTF.dll

I really shouldn't have bothered with this basic debugging after you
got all testy w/me, I'm not a cygwin developer, just a general
computer scientist, trying to use common sense.

FWIW, listdlls is a sysinternals tool from microsoft.



More information about the Cygwin mailing list