From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from Ishtar.sc.tlinx.org (ishtar.tlinx.org [173.164.175.65]) by sourceware.org (Postfix) with ESMTPS id 956FB386FC1B for ; Tue, 8 Jun 2021 13:05:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 956FB386FC1B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tlinx.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tlinx.org Received: from [192.168.3.12] (Athenae [192.168.3.12]) by Ishtar.sc.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id 158D5Pla007907; Tue, 8 Jun 2021 06:05:27 -0700 Message-ID: <60BF6ADB.304@tlinx.org> Date: Tue, 08 Jun 2021 06:04:27 -0700 From: L A Walsh User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mike Kaganski CC: "cygwin@cygwin.com" Subject: Re: Python for Windows reports wrong local time when run under Cygwin on Europe/Moscow TZ References: <5542c19d-8b1a-1f28-2003-fe9493ee9b56@mail.ru> <60BF5677.9060904@tlinx.org> <97024d79-16b2-98a0-d20a-b3e6915ad0d0@mail.ru> In-Reply-To: <97024d79-16b2-98a0-d20a-b3e6915ad0d0@mail.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 13:05:53 -0000 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:https://cygwin.com/faq/faq.html#faq.using.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 - www.sysinternals.com ------------------------------------------------------------------------------ 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. Linda > >