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

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

[Keith Thompson]

There is a known problem with the $TZ environment variable.

Here's a discussion from 2017:
https://cygwin.com/pipermail/cygwin/2017-May/232675.html

The problem is that both Cygwin and Windows use the $TZ environment
variable, but they interpret it differently.

The Windows handling of $TZ (or %TZ%) is documented here:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-160

For example, Pacific Time is represented as TZ=PST8PDT.

In Cygwin, my $TZ is set by default to "America/Los_Angeles".
Any Windows applications that I invoke from Cygwin, if they attempt
to determine the time zone, will behave inconsistently because they
don't see "America/Los_Angeles" as a valid time zone string.

I've worked around this by unsetting TZ in my .bash_profile .
Cygwin applications are still able to determine the correct time zone.

I suggest that Cygwin should *not* set the TZ environment variable.

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

[Brian Inglis]

On 2021-06-08 11:37, Keith Thompson via Cygwin wrote:
> There is a known problem with the $TZ environment variable.
> 
> Here's a discussion from 2017:
> https://cygwin.com/pipermail/cygwin/2017-May/232675.html
> 
> The problem is that both Cygwin and Windows use the $TZ environment
> variable, but they interpret it differently.
> 
> The Windows handling of $TZ (or %TZ%) is documented here:
> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-160
> 
> For example, Pacific Time is represented as TZ=PST8PDT.
> 
> In Cygwin, my $TZ is set by default to "America/Los_Angeles".
> Any Windows applications that I invoke from Cygwin, if they attempt
> to determine the time zone, will behave inconsistently because they
> don't see "America/Los_Angeles" as a valid time zone string.
> 
> I've worked around this by unsetting TZ in my .bash_profile .
> Cygwin applications are still able to determine the correct time zone.
> 
> I suggest that Cygwin should *not* set the TZ environment variable.

In that case, those affected should comment out the last line of each:

$ tail /etc/profile.d/tzset.*sh
==> /etc/profile.d/tzset.csh <==
# Modifying /etc/profile.d/tzset.csh directly will prevent
# setup from updating it.

# System-wide tzset.csh file

#Uses the geographical location setting of the user to find the right
#mapping, rather than the locale setting.  Only on Windows 2000 which
#doesn't know about the user's geographical location, or if fetching
#the geographical location fails, it falls back to the user's locale.
if ( $?TZ == 0 ) setenv TZ `/usr/bin/tzset`

==> /etc/profile.d/tzset.sh <==
# Modifying /etc/profile.d/tzset.sh directly will prevent
# setup from updating it.

# System-wide tzset.sh file

#Uses the geographical location setting of the user to find the right
#mapping, rather than the locale setting.  Only on Windows 2000 which
#doesn't know about the user's geographical location, or if fetching
#the geographical location fails, it falls back to the user's locale.
test -z "$TZ" && export TZ=$(/usr/bin/tzset)

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

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

[Keith Thompson]

[Sorry if the threading is messed up.  I don't subscribe, so I'm
constructing this message from the web interface.  It should at least
show up under the correct subject.]

Brian Inglis wrote:
> On 2021-06-08 14:03, Mike Kaganski via Cygwin wrote:
> > On 08.06.2021 16:04, L A Walsh wrote:
> >> 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?
> >
> > FTR: filed https://bugs.python.org/issue44352.
>
> See Keith Thompson subthread and my reply with suggested fix:
>
> https://cygwin.com/pipermail/cygwin/2021-June/248692.html
>
> Windows does not recognize zoneinfo time zone identifiers in TZ only
> base format POSIX TZ strings with three alphabetic character identifiers:
>
> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-160
>
> That assumes US switch date "rules": for all years up to current, or
> just DST, and whether pre- or post-2007 is unstated!
>
> Otherwise it defaults to regional settings, used by Cygwin to map to
> zoneinfo time zone identifiers, so if Python for Windows could clear TZ
> before it is read by MSVCRT, it should DTRT.
>
> Windows does not recognize expanded POSIX TZ format strings with <>
> quoted alphanumeric characters, "-", "+", and start and end dates/times:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#bottom
>
> which make them usable outside of the US.

Summary: IMHO Cygwin should adapt its default TZ setting to work
with Windows.

The suggestion is to modify Python for Windows so it can deal with
the TZ format used by Cygwin.  I haven't used Python for Windows, but
as far as I know it's unrelated to Cygwin; rather it, like Cygwin, is
intended to work on top of Windows.  I'm not convinced it's appropriate
to ask Python for Windows to make a change purely for the sake of
interoperating with Cygwin, which many PfW users presumably aren't
even using.

I've run into another application that has problems with Cygwin's
settings of $TZ.  It was a internal test application that isn't
going to change its timezone handling just for this problem.

The ideal solution would be for Windows to recognize TZ values like
"America/Los_Angeles", but that's not likely to happen any time soon.

My suggestion, since Cygwin is supposed to interoperate with Windows,
is one of the following:

- Cygwin should avoid setting TZ to a value that Windows doesn't recognize
  (if I set TZ=PST8PDT, everything seems to work correctly); OR

- Cygwin shouldn't set TZ at all by default.  (I've updated my
  $HOME/.bash_profile on Cygwin to unset TZ, and Cygwin commands seem
  to work correctly with TZ unset); OR

- Cygwin, when invoking a non-Cygwin executable, should first either
  unset TZ or translate it to a format that Windows will recognize.
  I have no idea how difficult that would be.

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

[Brian Inglis]

On 2021-06-09 16:31, Keith Thompson via Cygwin wrote:
> [Sorry if the threading is messed up.  I don't subscribe, so I'm
> constructing this message from the web interface.  It should at least
> show up under the correct subject.]
> 
> Brian Inglis wrote:
>> On 2021-06-08 14:03, Mike Kaganski via Cygwin wrote:
>>> On 08.06.2021 16:04, L A Walsh wrote:
>>>> 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?
>>>
>>> FTR: filed https://bugs.python.org/issue44352.
>>
>> See Keith Thompson subthread and my reply with suggested fix:
>>
>> https://cygwin.com/pipermail/cygwin/2021-June/248692.html
>>
>> Windows does not recognize zoneinfo time zone identifiers in TZ only
>> base format POSIX TZ strings with three alphabetic character identifiers:
>>
>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-160
>>
>> That assumes US switch date "rules": for all years up to current, or
>> just DST, and whether pre- or post-2007 is unstated!
>>
>> Otherwise it defaults to regional settings, used by Cygwin to map to
>> zoneinfo time zone identifiers, so if Python for Windows could clear TZ
>> before it is read by MSVCRT, it should DTRT.
>>
>> Windows does not recognize expanded POSIX TZ format strings with <>
>> quoted alphanumeric characters, "-", "+", and start and end dates/times:
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#bottom
>>
>> which make them usable outside of the US.
> 
> Summary: IMHO Cygwin should adapt its default TZ setting to work
> with Windows.
> 
> The suggestion is to modify Python for Windows so it can deal with
> the TZ format used by Cygwin.  I haven't used Python for Windows, but
> as far as I know it's unrelated to Cygwin; rather it, like Cygwin, is
> intended to work on top of Windows.  I'm not convinced it's appropriate
> to ask Python for Windows to make a change purely for the sake of
> interoperating with Cygwin, which many PfW users presumably aren't
> even using.
> 
> I've run into another application that has problems with Cygwin's
> settings of $TZ.  It was a internal test application that isn't
> going to change its timezone handling just for this problem.
> 
> The ideal solution would be for Windows to recognize TZ values like
> "America/Los_Angeles", but that's not likely to happen any time soon.
> 
> My suggestion, since Cygwin is supposed to interoperate with Windows,
> is one of the following:
> 
> - Cygwin should avoid setting TZ to a value that Windows doesn't recognize
>    (if I set TZ=PST8PDT, everything seems to work correctly); OR
> 
> - Cygwin shouldn't set TZ at all by default.  (I've updated my
>    $HOME/.bash_profile on Cygwin to unset TZ, and Cygwin commands seem
>    to work correctly with TZ unset); OR
> 
> - Cygwin, when invoking a non-Cygwin executable, should first either
>    unset TZ or translate it to a format that Windows will recognize.
>    I have no idea how difficult that would be.

Impossible to set Windows TZ usefully as it obeys unstated US DST rules 
(like posixrules, perhaps 2007+?), and may have limits on hour offset 
magnitudes.
MS libraries are stuck at POSIX 1996 and C 99 subset compatibility, but 
non-standard-conformant including which headers contain definitions:

	https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility?view=msvc-160

It may be possible to unset TZ when running non-Cygwin programs 
(possibly behind a CYGWIN env var setting e.g. winnotz) by adding TZ= to 
conv_envvars, and writing new helper functions env_tz_to_posix to call 
tzset and env_tz_to_win32 to remove TZ in:

	https://sourceware.org/git/?p=newlib-cygwin.git;f=winsup/cygwin/environ.cc;a=blob

What is the opinion on this from both Windows users and Cygwin patchers?

[I am one of those folks who like maximum POSIX/Linux compatibility from 
my environment and scripts, so maintain files/sym-/links like /run, 
/etc/timezone, /etc/localtime from local 0p_/zp_ postinstall scripts.]

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

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

[Ken Brown]

On 6/9/2021 10:36 PM, Brian Inglis wrote:
> On 2021-06-09 16:31, Keith Thompson via Cygwin wrote:
>> [Sorry if the threading is messed up.  I don't subscribe, so I'm
>> constructing this message from the web interface.  It should at least
>> show up under the correct subject.]
>>
>> Brian Inglis wrote:
>>> On 2021-06-08 14:03, Mike Kaganski via Cygwin wrote:
>>>> On 08.06.2021 16:04, L A Walsh wrote:
>>>>> 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?
>>>>
>>>> FTR: filed https://bugs.python.org/issue44352.
>>>
>>> See Keith Thompson subthread and my reply with suggested fix:
>>>
>>> https://cygwin.com/pipermail/cygwin/2021-June/248692.html
>>>
>>> Windows does not recognize zoneinfo time zone identifiers in TZ only
>>> base format POSIX TZ strings with three alphabetic character identifiers:
>>>
>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-160 
>>>
>>>
>>> That assumes US switch date "rules": for all years up to current, or
>>> just DST, and whether pre- or post-2007 is unstated!
>>>
>>> Otherwise it defaults to regional settings, used by Cygwin to map to
>>> zoneinfo time zone identifiers, so if Python for Windows could clear TZ
>>> before it is read by MSVCRT, it should DTRT.
>>>
>>> Windows does not recognize expanded POSIX TZ format strings with <>
>>> quoted alphanumeric characters, "-", "+", and start and end dates/times:
>>>
>>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#bottom
>>>
>>> which make them usable outside of the US.
>>
>> Summary: IMHO Cygwin should adapt its default TZ setting to work
>> with Windows.
>>
>> The suggestion is to modify Python for Windows so it can deal with
>> the TZ format used by Cygwin.  I haven't used Python for Windows, but
>> as far as I know it's unrelated to Cygwin; rather it, like Cygwin, is
>> intended to work on top of Windows.  I'm not convinced it's appropriate
>> to ask Python for Windows to make a change purely for the sake of
>> interoperating with Cygwin, which many PfW users presumably aren't
>> even using.
>>
>> I've run into another application that has problems with Cygwin's
>> settings of $TZ.  It was a internal test application that isn't
>> going to change its timezone handling just for this problem.
>>
>> The ideal solution would be for Windows to recognize TZ values like
>> "America/Los_Angeles", but that's not likely to happen any time soon.
>>
>> My suggestion, since Cygwin is supposed to interoperate with Windows,
>> is one of the following:
>>
>> - Cygwin should avoid setting TZ to a value that Windows doesn't recognize
>>    (if I set TZ=PST8PDT, everything seems to work correctly); OR
>>
>> - Cygwin shouldn't set TZ at all by default.  (I've updated my
>>    $HOME/.bash_profile on Cygwin to unset TZ, and Cygwin commands seem
>>    to work correctly with TZ unset); OR
>>
>> - Cygwin, when invoking a non-Cygwin executable, should first either
>>    unset TZ or translate it to a format that Windows will recognize.
>>    I have no idea how difficult that would be.
> 
> Impossible to set Windows TZ usefully as it obeys unstated US DST rules (like 
> posixrules, perhaps 2007+?), and may have limits on hour offset magnitudes.
> MS libraries are stuck at POSIX 1996 and C 99 subset compatibility, but 
> non-standard-conformant including which headers contain definitions:
> 
>      https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility?view=msvc-160
> 
> It may be possible to unset TZ when running non-Cygwin programs (possibly behind 
> a CYGWIN env var setting e.g. winnotz) by adding TZ= to conv_envvars, and 
> writing new helper functions env_tz_to_posix to call tzset and env_tz_to_win32 
> to remove TZ in:
> 
>      https://sourceware.org/git/?p=newlib-cygwin.git;f=winsup/cygwin/environ.cc;a=blob
> 
> What is the opinion on this from both Windows users and Cygwin patchers?

I'm not convinced it's worth the trouble.  I haven't seen anyone argue that it's 
useful for Cygwin to set TZ, and I have seen an argument that it's harmful:

   https://cygwin.com/pipermail/cygwin/2017-May/232675.html .

So I prefer Keith's second suggestion:

 >> - Cygwin shouldn't set TZ at all by default.

Ken

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

[KAVALAGIOS Panagiotis (EEAS-EXT)]

> -----Original Message-----
> Behalf Of Ken Brown via Cygwin
> Sent: 10 June 2021 16:58
> Subject: Re: Python for Windows reports wrong local time when run under
> Cygwin on Europe/Moscow TZ
> 
 
> I'm not convinced it's worth the trouble.  I haven't seen anyone argue that
> it's useful for Cygwin to set TZ, and I have seen an argument that it's harmful:
> 
>    https://cygwin.com/pipermail/cygwin/2017-May/232675.html .
> 
> So I prefer Keith's second suggestion:
> 
>  >> - Cygwin shouldn't set TZ at all by default.

I also support that TZ environmental variable shouldn't be set by default in Cygwin. I don't even remember any Solaris, HP-UX, IRIX, Digital Unix, FreeBSD, Linux etc. setting it by default. It was up to the user to define it and enjoy with the different output of the "date" command.

It might have been introduced in Cygwin to resolve some issues on the programs that need POSIX TZ format, but for the rest of the programs that still consult the windows format will fail. It would be more reasonable to use a wrapper script for those programs that have issues to set it explicitly to the expected windows default format.

Kind regards,

Panos Kavalagios

Application Architect
CONSULIAT (under contract with the EEAS)
BA.BS.3.IS
Office: EEAS B100 Floor 5 Area 048
Rue Belliard 100, 1000 Brussels
Phone: +32 2 584 6017

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

[Brian Inglis]

On 2021-06-10 08:57, Ken Brown via Cygwin wrote:
> On 6/9/2021 10:36 PM, Brian Inglis wrote:
>> On 2021-06-09 16:31, Keith Thompson via Cygwin wrote:
>>> [Sorry if the threading is messed up.  I don't subscribe, so I'm
>>> constructing this message from the web interface.  It should at least
>>> show up under the correct subject.]
>>>
>>> Brian Inglis wrote:
>>>> On 2021-06-08 14:03, Mike Kaganski via Cygwin wrote:
>>>>> On 08.06.2021 16:04, L A Walsh wrote:
>>>>>> 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?
>>>>>
>>>>> FTR: filed https://bugs.python.org/issue44352.
>>>>
>>>> See Keith Thompson subthread and my reply with suggested fix:
>>>>
>>>> https://cygwin.com/pipermail/cygwin/2021-June/248692.html
>>>>
>>>> Windows does not recognize zoneinfo time zone identifiers in TZ only
>>>> base format POSIX TZ strings with three alphabetic character 
>>>> identifiers:
>>>>
>>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-160 
>>>>
>>>>
>>>> That assumes US switch date "rules": for all years up to current, or
>>>> just DST, and whether pre- or post-2007 is unstated!
>>>>
>>>> Otherwise it defaults to regional settings, used by Cygwin to map to
>>>> zoneinfo time zone identifiers, so if Python for Windows could clear TZ
>>>> before it is read by MSVCRT, it should DTRT.
>>>>
>>>> Windows does not recognize expanded POSIX TZ format strings with <>
>>>> quoted alphanumeric characters, "-", "+", and start and end 
>>>> dates/times:
>>>>
>>>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#bottom 
>>>>
>>>>
>>>> which make them usable outside of the US.
>>>
>>> Summary: IMHO Cygwin should adapt its default TZ setting to work
>>> with Windows.
>>>
>>> The suggestion is to modify Python for Windows so it can deal with
>>> the TZ format used by Cygwin.  I haven't used Python for Windows, but
>>> as far as I know it's unrelated to Cygwin; rather it, like Cygwin, is
>>> intended to work on top of Windows.  I'm not convinced it's appropriate
>>> to ask Python for Windows to make a change purely for the sake of
>>> interoperating with Cygwin, which many PfW users presumably aren't
>>> even using.
>>>
>>> I've run into another application that has problems with Cygwin's
>>> settings of $TZ.  It was a internal test application that isn't
>>> going to change its timezone handling just for this problem.
>>>
>>> The ideal solution would be for Windows to recognize TZ values like
>>> "America/Los_Angeles", but that's not likely to happen any time soon.
>>>
>>> My suggestion, since Cygwin is supposed to interoperate with Windows,
>>> is one of the following:
>>>
>>> - Cygwin should avoid setting TZ to a value that Windows doesn't 
>>> recognize
>>>    (if I set TZ=PST8PDT, everything seems to work correctly); OR
>>>
>>> - Cygwin shouldn't set TZ at all by default.  (I've updated my
>>>    $HOME/.bash_profile on Cygwin to unset TZ, and Cygwin commands seem
>>>    to work correctly with TZ unset); OR
>>>
>>> - Cygwin, when invoking a non-Cygwin executable, should first either
>>>    unset TZ or translate it to a format that Windows will recognize.
>>>    I have no idea how difficult that would be.
>>
>> Impossible to set Windows TZ usefully as it obeys unstated US DST 
>> rules (like posixrules, perhaps 2007+?), and may have limits on hour 
>> offset magnitudes.
>> MS libraries are stuck at POSIX 1996 and C 99 subset compatibility, 
>> but non-standard-conformant including which headers contain definitions:
>>
>>      https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility?view=msvc-160 
>>
>>
>> It may be possible to unset TZ when running non-Cygwin programs 
>> (possibly behind a CYGWIN env var setting e.g. winnotz) by adding TZ= 
>> to conv_envvars, and writing new helper functions env_tz_to_posix to 
>> call tzset and env_tz_to_win32 to remove TZ in:
>>
>>      https://sourceware.org/git/?p=newlib-cygwin.git;f=winsup/cygwin/environ.cc;a=blob 
>>
>>
>> What is the opinion on this from both Windows users and Cygwin patchers?
> 
> I'm not convinced it's worth the trouble.  I haven't seen anyone argue 
> that it's useful for Cygwin to set TZ, and I have seen an argument that 
> it's harmful:
> 
>    https://cygwin.com/pipermail/cygwin/2017-May/232675.html .
> 
> So I prefer Keith's second suggestion:
> 
>  >> - Cygwin shouldn't set TZ at all by default.

It does so in default startup scripts to get the correct behaviour from 
Cygwin DLL and programs, so it's up to users to change the default 
profiles /etc/profile.d/tzset.{,c}sh to disable that, perhaps by putting 
required edits into a local 0p_/zp_ postinstall script.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

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

[Ken Brown]

On 6/10/2021 2:31 PM, Brian Inglis wrote:
> On 2021-06-10 08:57, Ken Brown via Cygwin wrote:
>> On 6/9/2021 10:36 PM, Brian Inglis wrote:
>>> On 2021-06-09 16:31, Keith Thompson via Cygwin wrote:
>>>> [Sorry if the threading is messed up.  I don't subscribe, so I'm
>>>> constructing this message from the web interface.  It should at least
>>>> show up under the correct subject.]
>>>>
>>>> Brian Inglis wrote:
>>>>> On 2021-06-08 14:03, Mike Kaganski via Cygwin wrote:
>>>>>> On 08.06.2021 16:04, L A Walsh wrote:
>>>>>>> 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?
>>>>>>
>>>>>> FTR: filed https://bugs.python.org/issue44352.
>>>>>
>>>>> See Keith Thompson subthread and my reply with suggested fix:
>>>>>
>>>>> https://cygwin.com/pipermail/cygwin/2021-June/248692.html
>>>>>
>>>>> Windows does not recognize zoneinfo time zone identifiers in TZ only
>>>>> base format POSIX TZ strings with three alphabetic character identifiers:
>>>>>
>>>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-160 
>>>>>
>>>>>
>>>>> That assumes US switch date "rules": for all years up to current, or
>>>>> just DST, and whether pre- or post-2007 is unstated!
>>>>>
>>>>> Otherwise it defaults to regional settings, used by Cygwin to map to
>>>>> zoneinfo time zone identifiers, so if Python for Windows could clear TZ
>>>>> before it is read by MSVCRT, it should DTRT.
>>>>>
>>>>> Windows does not recognize expanded POSIX TZ format strings with <>
>>>>> quoted alphanumeric characters, "-", "+", and start and end dates/times:
>>>>>
>>>>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#bottom 
>>>>>
>>>>>
>>>>> which make them usable outside of the US.
>>>>
>>>> Summary: IMHO Cygwin should adapt its default TZ setting to work
>>>> with Windows.
>>>>
>>>> The suggestion is to modify Python for Windows so it can deal with
>>>> the TZ format used by Cygwin.  I haven't used Python for Windows, but
>>>> as far as I know it's unrelated to Cygwin; rather it, like Cygwin, is
>>>> intended to work on top of Windows.  I'm not convinced it's appropriate
>>>> to ask Python for Windows to make a change purely for the sake of
>>>> interoperating with Cygwin, which many PfW users presumably aren't
>>>> even using.
>>>>
>>>> I've run into another application that has problems with Cygwin's
>>>> settings of $TZ.  It was a internal test application that isn't
>>>> going to change its timezone handling just for this problem.
>>>>
>>>> The ideal solution would be for Windows to recognize TZ values like
>>>> "America/Los_Angeles", but that's not likely to happen any time soon.
>>>>
>>>> My suggestion, since Cygwin is supposed to interoperate with Windows,
>>>> is one of the following:
>>>>
>>>> - Cygwin should avoid setting TZ to a value that Windows doesn't recognize
>>>>    (if I set TZ=PST8PDT, everything seems to work correctly); OR
>>>>
>>>> - Cygwin shouldn't set TZ at all by default.  (I've updated my
>>>>    $HOME/.bash_profile on Cygwin to unset TZ, and Cygwin commands seem
>>>>    to work correctly with TZ unset); OR
>>>>
>>>> - Cygwin, when invoking a non-Cygwin executable, should first either
>>>>    unset TZ or translate it to a format that Windows will recognize.
>>>>    I have no idea how difficult that would be.
>>>
>>> Impossible to set Windows TZ usefully as it obeys unstated US DST rules (like 
>>> posixrules, perhaps 2007+?), and may have limits on hour offset magnitudes.
>>> MS libraries are stuck at POSIX 1996 and C 99 subset compatibility, but 
>>> non-standard-conformant including which headers contain definitions:
>>>
>>>      https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility?view=msvc-160 
>>>
>>>
>>> It may be possible to unset TZ when running non-Cygwin programs (possibly 
>>> behind a CYGWIN env var setting e.g. winnotz) by adding TZ= to conv_envvars, 
>>> and writing new helper functions env_tz_to_posix to call tzset and 
>>> env_tz_to_win32 to remove TZ in:
>>>
>>>      https://sourceware.org/git/?p=newlib-cygwin.git;f=winsup/cygwin/environ.cc;a=blob 
>>>
>>>
>>> What is the opinion on this from both Windows users and Cygwin patchers?
>>
>> I'm not convinced it's worth the trouble.  I haven't seen anyone argue that 
>> it's useful for Cygwin to set TZ, and I have seen an argument that it's harmful:
>>
>>    https://cygwin.com/pipermail/cygwin/2017-May/232675.html .
>>
>> So I prefer Keith's second suggestion:
>>
>>  >> - Cygwin shouldn't set TZ at all by default.
> 
> It does so in default startup scripts

Right, and I'm agreeing with Bruno (in the message cited above) that the default 
startup scripts should stop doing that.

> to get the correct behaviour from Cygwin 
> DLL and programs,

Can you be more specific?  What goes wrong if TZ is not set?  I haven't seen any 
POSIX or Linux documentation that says it should be set, and I've just checked 
on two different Linux distros that it's not set by default.

Ken

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

[ASSI]

Ken Brown via Cygwin writes:
> Can you be more specific?  What goes wrong if TZ is not set?  I
> haven't seen any POSIX or Linux documentation that says it should be
> set, and I've just checked on two different Linux distros that it's
> not set by default.

The scripts in base-files were introduced in 2012 after an explicit
request by Corinna:

https://sourceware.org/legacy-ml/cygwin-developers/2012-01/msg00042.html

Whether any or all of this is still relevant needs to be checked before
we turn around and change the default again.

You can always change it locally by modifying the scripts so that the
defaults from base-files are not used anymore.  If you'd generally want
to do that I would recommend to create a local package that does all
these modifications to make it portable across all your systems and
re-installs.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

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

[Ken Brown]

On 6/11/2021 1:38 AM, ASSI wrote:
> Ken Brown via Cygwin writes:
>> Can you be more specific?  What goes wrong if TZ is not set?  I
>> haven't seen any POSIX or Linux documentation that says it should be
>> set, and I've just checked on two different Linux distros that it's
>> not set by default.
> 
> The scripts in base-files were introduced in 2012 after an explicit
> request by Corinna:
> 
> https://sourceware.org/legacy-ml/cygwin-developers/2012-01/msg00042.html
> 
> Whether any or all of this is still relevant needs to be checked before
> we turn around and change the default again.

Thanks, I wasn't aware of the history.  Let's wait until Corinna has a chance to 
chime in.

Ken

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

[Brian Inglis]

On 2021-06-10 13:50, Ken Brown via Cygwin wrote:
> On 6/10/2021 2:31 PM, Brian Inglis wrote:
>> On 2021-06-10 08:57, Ken Brown via Cygwin wrote:
>>> On 6/9/2021 10:36 PM, Brian Inglis wrote:
>>>> On 2021-06-09 16:31, Keith Thompson via Cygwin wrote:
>>>>> [Sorry if the threading is messed up.  I don't subscribe, so I'm
>>>>> constructing this message from the web interface.  It should at least
>>>>> show up under the correct subject.]
>>>>>
>>>>> Brian Inglis wrote:
>>>>>> On 2021-06-08 14:03, Mike Kaganski via Cygwin wrote:
>>>>>>> On 08.06.2021 16:04, L A Walsh wrote:
>>>>>>>> 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?
>>>>>>>
>>>>>>> FTR: filed https://bugs.python.org/issue44352.
>>>>>>
>>>>>> See Keith Thompson subthread and my reply with suggested fix:
>>>>>>
>>>>>> https://cygwin.com/pipermail/cygwin/2021-June/248692.html
>>>>>>
>>>>>> Windows does not recognize zoneinfo time zone identifiers in TZ only
>>>>>> base format POSIX TZ strings with three alphabetic character 
>>>>>> identifiers:
>>>>>>
>>>>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-160 
>>>>>>
>>>>>>
>>>>>> That assumes US switch date "rules": for all years up to current, or
>>>>>> just DST, and whether pre- or post-2007 is unstated!
>>>>>>
>>>>>> Otherwise it defaults to regional settings, used by Cygwin to map to
>>>>>> zoneinfo time zone identifiers, so if Python for Windows could 
>>>>>> clear TZ
>>>>>> before it is read by MSVCRT, it should DTRT.
>>>>>>
>>>>>> Windows does not recognize expanded POSIX TZ format strings with <>
>>>>>> quoted alphanumeric characters, "-", "+", and start and end 
>>>>>> dates/times:
>>>>>>
>>>>>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#bottom 
>>>>>>
>>>>>>
>>>>>> which make them usable outside of the US.
>>>>>
>>>>> Summary: IMHO Cygwin should adapt its default TZ setting to work
>>>>> with Windows.
>>>>>
>>>>> The suggestion is to modify Python for Windows so it can deal with
>>>>> the TZ format used by Cygwin.  I haven't used Python for Windows, but
>>>>> as far as I know it's unrelated to Cygwin; rather it, like Cygwin, is
>>>>> intended to work on top of Windows.  I'm not convinced it's 
>>>>> appropriate
>>>>> to ask Python for Windows to make a change purely for the sake of
>>>>> interoperating with Cygwin, which many PfW users presumably aren't
>>>>> even using.
>>>>>
>>>>> I've run into another application that has problems with Cygwin's
>>>>> settings of $TZ.  It was a internal test application that isn't
>>>>> going to change its timezone handling just for this problem.
>>>>>
>>>>> The ideal solution would be for Windows to recognize TZ values like
>>>>> "America/Los_Angeles", but that's not likely to happen any time soon.
>>>>>
>>>>> My suggestion, since Cygwin is supposed to interoperate with Windows,
>>>>> is one of the following:
>>>>>
>>>>> - Cygwin should avoid setting TZ to a value that Windows doesn't 
>>>>> recognize
>>>>>    (if I set TZ=PST8PDT, everything seems to work correctly); OR
>>>>>
>>>>> - Cygwin shouldn't set TZ at all by default.  (I've updated my
>>>>>    $HOME/.bash_profile on Cygwin to unset TZ, and Cygwin commands seem
>>>>>    to work correctly with TZ unset); OR
>>>>>
>>>>> - Cygwin, when invoking a non-Cygwin executable, should first either
>>>>>    unset TZ or translate it to a format that Windows will recognize.
>>>>>    I have no idea how difficult that would be.
>>>>
>>>> Impossible to set Windows TZ usefully as it obeys unstated US DST 
>>>> rules (like posixrules, perhaps 2007+?), and may have limits on hour 
>>>> offset magnitudes.
>>>> MS libraries are stuck at POSIX 1996 and C 99 subset compatibility, 
>>>> but non-standard-conformant including which headers contain 
>>>> definitions:
>>>>
>>>>      https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility?view=msvc-160 
>>>>
>>>>
>>>> It may be possible to unset TZ when running non-Cygwin programs 
>>>> (possibly behind a CYGWIN env var setting e.g. winnotz) by adding 
>>>> TZ= to conv_envvars, and writing new helper functions 
>>>> env_tz_to_posix to call tzset and env_tz_to_win32 to remove TZ in:
>>>>
>>>>      https://sourceware.org/git/?p=newlib-cygwin.git;f=winsup/cygwin/environ.cc;a=blob 
>>>>
>>>>
>>>> What is the opinion on this from both Windows users and Cygwin 
>>>> patchers?
>>>
>>> I'm not convinced it's worth the trouble.  I haven't seen anyone 
>>> argue that it's useful for Cygwin to set TZ, and I have seen an 
>>> argument that it's harmful:
>>>
>>>    https://cygwin.com/pipermail/cygwin/2017-May/232675.html .
>>>
>>> So I prefer Keith's second suggestion:
>>>
>>>  >> - Cygwin shouldn't set TZ at all by default.
>>
>> It does so in default startup scripts
> 
> Right, and I'm agreeing with Bruno (in the message cited above) that the 
> default startup scripts should stop doing that.
> 
>> to get the correct behaviour from Cygwin DLL and programs,
> 
> Can you be more specific?  What goes wrong if TZ is not set?  I haven't 
> seen any POSIX or Linux documentation that says it should be set, and 
> I've just checked on two different Linux distros that it's not set by 
> default.

I would expect that date, ls, etc. would output UTC, or perhaps PST or 
EST, depending on tzdata builds of Factory (tz -00/unset) and posixrules 
(Cygwin PST, Debian EST) and use during system setup and startup, unless 
/etc/timezone and/or /etc/localtime are set, and used during startup, 
often by systemd, or login by profiles.

How do you set or get useful local time on your systems?

On Debian I "sudo dpkg-reconfigure tzdata" to set America/Edmonton after 
install, locale-gen a few en_?? locales, and localedef personal local 
customizations to en_CA.

I can't remember what I may have done setting up other distros when I 
tried them.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

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

[Ken Brown]

On 6/11/2021 1:33 PM, Brian Inglis wrote:
> On 2021-06-10 13:50, Ken Brown via Cygwin wrote:
>> On 6/10/2021 2:31 PM, Brian Inglis wrote:
>>> On 2021-06-10 08:57, Ken Brown via Cygwin wrote:
>>>> On 6/9/2021 10:36 PM, Brian Inglis wrote:
>>>>> On 2021-06-09 16:31, Keith Thompson via Cygwin wrote:
>>>>>> [Sorry if the threading is messed up.  I don't subscribe, so I'm
>>>>>> constructing this message from the web interface.  It should at least
>>>>>> show up under the correct subject.]
>>>>>>
>>>>>> Brian Inglis wrote:
>>>>>>> On 2021-06-08 14:03, Mike Kaganski via Cygwin wrote:
>>>>>>>> On 08.06.2021 16:04, L A Walsh wrote:
>>>>>>>>> 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?
>>>>>>>>
>>>>>>>> FTR: filed https://bugs.python.org/issue44352.
>>>>>>>
>>>>>>> See Keith Thompson subthread and my reply with suggested fix:
>>>>>>>
>>>>>>> https://cygwin.com/pipermail/cygwin/2021-June/248692.html
>>>>>>>
>>>>>>> Windows does not recognize zoneinfo time zone identifiers in TZ only
>>>>>>> base format POSIX TZ strings with three alphabetic character identifiers:
>>>>>>>
>>>>>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-160 
>>>>>>>
>>>>>>>
>>>>>>> That assumes US switch date "rules": for all years up to current, or
>>>>>>> just DST, and whether pre- or post-2007 is unstated!
>>>>>>>
>>>>>>> Otherwise it defaults to regional settings, used by Cygwin to map to
>>>>>>> zoneinfo time zone identifiers, so if Python for Windows could clear TZ
>>>>>>> before it is read by MSVCRT, it should DTRT.
>>>>>>>
>>>>>>> Windows does not recognize expanded POSIX TZ format strings with <>
>>>>>>> quoted alphanumeric characters, "-", "+", and start and end dates/times:
>>>>>>>
>>>>>>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#bottom 
>>>>>>>
>>>>>>>
>>>>>>> which make them usable outside of the US.
>>>>>>
>>>>>> Summary: IMHO Cygwin should adapt its default TZ setting to work
>>>>>> with Windows.
>>>>>>
>>>>>> The suggestion is to modify Python for Windows so it can deal with
>>>>>> the TZ format used by Cygwin.  I haven't used Python for Windows, but
>>>>>> as far as I know it's unrelated to Cygwin; rather it, like Cygwin, is
>>>>>> intended to work on top of Windows.  I'm not convinced it's appropriate
>>>>>> to ask Python for Windows to make a change purely for the sake of
>>>>>> interoperating with Cygwin, which many PfW users presumably aren't
>>>>>> even using.
>>>>>>
>>>>>> I've run into another application that has problems with Cygwin's
>>>>>> settings of $TZ.  It was a internal test application that isn't
>>>>>> going to change its timezone handling just for this problem.
>>>>>>
>>>>>> The ideal solution would be for Windows to recognize TZ values like
>>>>>> "America/Los_Angeles", but that's not likely to happen any time soon.
>>>>>>
>>>>>> My suggestion, since Cygwin is supposed to interoperate with Windows,
>>>>>> is one of the following:
>>>>>>
>>>>>> - Cygwin should avoid setting TZ to a value that Windows doesn't recognize
>>>>>>    (if I set TZ=PST8PDT, everything seems to work correctly); OR
>>>>>>
>>>>>> - Cygwin shouldn't set TZ at all by default.  (I've updated my
>>>>>>    $HOME/.bash_profile on Cygwin to unset TZ, and Cygwin commands seem
>>>>>>    to work correctly with TZ unset); OR
>>>>>>
>>>>>> - Cygwin, when invoking a non-Cygwin executable, should first either
>>>>>>    unset TZ or translate it to a format that Windows will recognize.
>>>>>>    I have no idea how difficult that would be.
>>>>>
>>>>> Impossible to set Windows TZ usefully as it obeys unstated US DST rules 
>>>>> (like posixrules, perhaps 2007+?), and may have limits on hour offset 
>>>>> magnitudes.
>>>>> MS libraries are stuck at POSIX 1996 and C 99 subset compatibility, but 
>>>>> non-standard-conformant including which headers contain definitions:
>>>>>
>>>>>      https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility?view=msvc-160 
>>>>>
>>>>>
>>>>> It may be possible to unset TZ when running non-Cygwin programs (possibly 
>>>>> behind a CYGWIN env var setting e.g. winnotz) by adding TZ= to 
>>>>> conv_envvars, and writing new helper functions env_tz_to_posix to call 
>>>>> tzset and env_tz_to_win32 to remove TZ in:
>>>>>
>>>>>      https://sourceware.org/git/?p=newlib-cygwin.git;f=winsup/cygwin/environ.cc;a=blob 
>>>>>
>>>>>
>>>>> What is the opinion on this from both Windows users and Cygwin patchers?
>>>>
>>>> I'm not convinced it's worth the trouble.  I haven't seen anyone argue that 
>>>> it's useful for Cygwin to set TZ, and I have seen an argument that it's 
>>>> harmful:
>>>>
>>>>    https://cygwin.com/pipermail/cygwin/2017-May/232675.html .
>>>>
>>>> So I prefer Keith's second suggestion:
>>>>
>>>>  >> - Cygwin shouldn't set TZ at all by default.
>>>
>>> It does so in default startup scripts
>>
>> Right, and I'm agreeing with Bruno (in the message cited above) that the 
>> default startup scripts should stop doing that.
>>
>>> to get the correct behaviour from Cygwin DLL and programs,
>>
>> Can you be more specific?  What goes wrong if TZ is not set?  I haven't seen 
>> any POSIX or Linux documentation that says it should be set, and I've just 
>> checked on two different Linux distros that it's not set by default.
> 
> I would expect that date, ls, etc. would output UTC, or perhaps PST or EST, 
> depending on tzdata builds of Factory (tz -00/unset) and posixrules (Cygwin PST, 
> Debian EST) and use during system setup and startup, unless /etc/timezone and/or 
> /etc/localtime are set, and used during startup, often by systemd, or login by 
> profiles.

No, you can 'unset TZ' and everything works fine.  Try it yourself.

> How do you set or get useful local time on your systems?

Cygwin takes care of it.  If TZ is unset, Cygwin queries Windows via 
GetTimeZoneInformation.  See tzgetwintzi in 
winsup/cygwin/tzcode/localtime_wrapper.c.

Ken

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

[Brian Inglis]

On 2021-06-11 12:05, Ken Brown via Cygwin wrote:
> On 6/11/2021 1:33 PM, Brian Inglis wrote:
>> On 2021-06-10 13:50, Ken Brown via Cygwin wrote:
>>> On 6/10/2021 2:31 PM, Brian Inglis wrote:
>>>> On 2021-06-10 08:57, Ken Brown via Cygwin wrote:
>>>>> On 6/9/2021 10:36 PM, Brian Inglis wrote:
>>>>>> On 2021-06-09 16:31, Keith Thompson via Cygwin wrote:
>>>>>>> [Sorry if the threading is messed up.  I don't subscribe, so I'm
>>>>>>> constructing this message from the web interface.  It should at 
>>>>>>> least
>>>>>>> show up under the correct subject.]
>>>>>>>
>>>>>>> Brian Inglis wrote:
>>>>>>>> On 2021-06-08 14:03, Mike Kaganski via Cygwin wrote:
>>>>>>>>> On 08.06.2021 16:04, L A Walsh wrote:
>>>>>>>>>> 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?
>>>>>>>>>
>>>>>>>>> FTR: filed https://bugs.python.org/issue44352.
>>>>>>>>
>>>>>>>> See Keith Thompson subthread and my reply with suggested fix:
>>>>>>>>
>>>>>>>> https://cygwin.com/pipermail/cygwin/2021-June/248692.html
>>>>>>>>
>>>>>>>> Windows does not recognize zoneinfo time zone identifiers in TZ 
>>>>>>>> only
>>>>>>>> base format POSIX TZ strings with three alphabetic character 
>>>>>>>> identifiers:
>>>>>>>>
>>>>>>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-160 
>>>>>>>>
>>>>>>>>
>>>>>>>> That assumes US switch date "rules": for all years up to 
>>>>>>>> current, or
>>>>>>>> just DST, and whether pre- or post-2007 is unstated!
>>>>>>>>
>>>>>>>> Otherwise it defaults to regional settings, used by Cygwin to 
>>>>>>>> map to
>>>>>>>> zoneinfo time zone identifiers, so if Python for Windows could 
>>>>>>>> clear TZ
>>>>>>>> before it is read by MSVCRT, it should DTRT.
>>>>>>>>
>>>>>>>> Windows does not recognize expanded POSIX TZ format strings with <>
>>>>>>>> quoted alphanumeric characters, "-", "+", and start and end 
>>>>>>>> dates/times:
>>>>>>>>
>>>>>>>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#bottom 
>>>>>>>>
>>>>>>>>
>>>>>>>> which make them usable outside of the US.
>>>>>>>
>>>>>>> Summary: IMHO Cygwin should adapt its default TZ setting to work
>>>>>>> with Windows.
>>>>>>>
>>>>>>> The suggestion is to modify Python for Windows so it can deal with
>>>>>>> the TZ format used by Cygwin.  I haven't used Python for Windows, 
>>>>>>> but
>>>>>>> as far as I know it's unrelated to Cygwin; rather it, like 
>>>>>>> Cygwin, is
>>>>>>> intended to work on top of Windows.  I'm not convinced it's 
>>>>>>> appropriate
>>>>>>> to ask Python for Windows to make a change purely for the sake of
>>>>>>> interoperating with Cygwin, which many PfW users presumably aren't
>>>>>>> even using.
>>>>>>>
>>>>>>> I've run into another application that has problems with Cygwin's
>>>>>>> settings of $TZ.  It was a internal test application that isn't
>>>>>>> going to change its timezone handling just for this problem.
>>>>>>>
>>>>>>> The ideal solution would be for Windows to recognize TZ values like
>>>>>>> "America/Los_Angeles", but that's not likely to happen any time 
>>>>>>> soon.
>>>>>>>
>>>>>>> My suggestion, since Cygwin is supposed to interoperate with 
>>>>>>> Windows,
>>>>>>> is one of the following:
>>>>>>>
>>>>>>> - Cygwin should avoid setting TZ to a value that Windows doesn't 
>>>>>>> recognize
>>>>>>>    (if I set TZ=PST8PDT, everything seems to work correctly); OR
>>>>>>>
>>>>>>> - Cygwin shouldn't set TZ at all by default.  (I've updated my
>>>>>>>    $HOME/.bash_profile on Cygwin to unset TZ, and Cygwin commands 
>>>>>>> seem
>>>>>>>    to work correctly with TZ unset); OR
>>>>>>>
>>>>>>> - Cygwin, when invoking a non-Cygwin executable, should first either
>>>>>>>    unset TZ or translate it to a format that Windows will recognize.
>>>>>>>    I have no idea how difficult that would be.
>>>>>>
>>>>>> Impossible to set Windows TZ usefully as it obeys unstated US DST 
>>>>>> rules (like posixrules, perhaps 2007+?), and may have limits on 
>>>>>> hour offset magnitudes.
>>>>>> MS libraries are stuck at POSIX 1996 and C 99 subset 
>>>>>> compatibility, but non-standard-conformant including which headers 
>>>>>> contain definitions:
>>>>>>
>>>>>>      https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility?view=msvc-160 
>>>>>>
>>>>>>
>>>>>> It may be possible to unset TZ when running non-Cygwin programs 
>>>>>> (possibly behind a CYGWIN env var setting e.g. winnotz) by adding 
>>>>>> TZ= to conv_envvars, and writing new helper functions 
>>>>>> env_tz_to_posix to call tzset and env_tz_to_win32 to remove TZ in:
>>>>>>
>>>>>>      https://sourceware.org/git/?p=newlib-cygwin.git;f=winsup/cygwin/environ.cc;a=blob 
>>>>>>
>>>>>>
>>>>>> What is the opinion on this from both Windows users and Cygwin 
>>>>>> patchers?
>>>>>
>>>>> I'm not convinced it's worth the trouble.  I haven't seen anyone 
>>>>> argue that it's useful for Cygwin to set TZ, and I have seen an 
>>>>> argument that it's harmful:
>>>>>
>>>>>    https://cygwin.com/pipermail/cygwin/2017-May/232675.html .
>>>>>
>>>>> So I prefer Keith's second suggestion:
>>>>>
>>>>>  >> - Cygwin shouldn't set TZ at all by default.
>>>>
>>>> It does so in default startup scripts
>>>
>>> Right, and I'm agreeing with Bruno (in the message cited above) that 
>>> the default startup scripts should stop doing that.
>>>
>>>> to get the correct behaviour from Cygwin DLL and programs,
>>>
>>> Can you be more specific?  What goes wrong if TZ is not set?  I 
>>> haven't seen any POSIX or Linux documentation that says it should be 
>>> set, and I've just checked on two different Linux distros that it's 
>>> not set by default.

See original message:

	https://sourceware.org/pipermail/cygwin/2012-January/199548.html

Looks like the tzdb metadata is not fully populated, including zone 
abbreviations, though that could be patched to use <%z> like tzdata 
defaults where countries use only a single local time zone and no name 
(other than COUNTRY time, and maybe Winter Time or Summer Time, as in 
many European countries).

>> I would expect that date, ls, etc. would output UTC, or perhaps PST or 
>> EST, depending on tzdata builds of Factory (tz -00/unset) and 
>> posixrules (Cygwin PST, Debian EST) and use during system setup and 
>> startup, unless /etc/timezone and/or /etc/localtime are set, and used 
>> during startup, often by systemd, or login by profiles.
> 
> No, you can 'unset TZ' and everything works fine.  Try it yourself.

It works incorrectly before 2007 because of DST rule changes.
Cygwin effectively uses expanded POSIX rules with a single pair of 
transition dates, applied to all years.
Doesn't work for anything other than current time rules, as Cygwin 
doesn't (yet?) use historical "Dynamic" DST.
"Dynamic" DST was probably only added to Vista about 2006 because the US 
was changing rules in 2007.

See comments by MS TZ/DST blogger, commentator, and tzdb contributor 
Matt Johnson-Pint:

https://stackoverflow.com/questions/19838892/dynamic-dst-historical-data

where he suggest the poster uses tzdb instead of trying to fix Windows 
Dynamic DST rules!
[I could generate equivalent Windows Dynamic DST reg entries from tzdb, 
but tzdb allows relational holiday calendar rules like "May Mon<25" - 
the Monday before the 25th May (Victoria Day, CA which mostly coincides 
with Memorial Day, US), and generates up to 400 years of entries, which 
I don't think the registry would cope with too well!]

For Windows TZ updates see:

	https://support.microsoft.com/kb/914387

Support for rule changes from 2010:

	http://support.microsoft.com/gp/cp_dst

As a result, it does not have much in the way of history for times past 
(see links above and examples below), unlike the tzdb in tzdata package, 
which has full history back to 1970, and in some cases, back to before 
standard time (Local Mean Time); if you have the tzcode package 
installed, try zdump with your local time zone e.g.:

	$ zdump -Vc1800,2008 America/New_York

or use -Vc1800,2022 in other countries with more recent changes.

Many zones in the Middle East have up to four changes each year if  DST 
would be in effect during Ramadan (it is reverted temporarily during 
that month), and there are many recent rule changes in most other 
countries, even Europe where countries jumped around annually until they 
joined or decided to conform with the EU, similar to Canadian provinces 
and Mexican states deciding to conform with the US from 2007, although 
some zones in both countries changed their minds after that, and some 
dropped DST e.g. Yukon CA in 2020!)

 From MS comments about Ramadan not appearing in TZ history, with the 
implication that MS have kludged current timekeeping to handle a DST 
reversion, but may be unable to handle more than one transition a year, 
historical file timestamps from earlier in the year will be displayed 
incorrectly.

MS are issuing historical corrections for previous years for Windows 10, 
but it looks like earlier Windows versions are getting more outdated:

https://docs.microsoft.com/en-us/archive/blogs/dst2007/
https://techcommunity.microsoft.com/t5/Daylight-Saving-Time-Time-Zone/bg-p/DSTBlog

>> How do you set or get useful local time on your systems?
> 
> Cygwin takes care of it.  If TZ is unset, Cygwin queries Windows via 
> GetTimeZoneInformation.  See tzgetwintzi in 
> winsup/cygwin/tzcode/localtime_wrapper.c.

I was asking about your Linux/BSD systems.


[Dump of Windows tz info for my tz (from Cygwin regtool as it converts 
to decimal but does not dump REG_BINARY keys in full only the first 
eight bytes, and Windows reg to dump REG_BINARY keys in full):

$ win-reg-tzi.sh
HKLM/SYSTEM/CurrentControlSet/Control/TimeZoneInformation
Bias (REG_DWORD) = 0x000001a4 (420)
DaylightBias (REG_DWORD) = 0xffffffc4 (4294967236)
DaylightName (REG_SZ) = "@tzres.dll,-191"
DaylightStart (REG_BINARY) = 00 00 03 00 02 00 02 00
DynamicDaylightTimeDisabled (REG_DWORD) = 0x00000000 (0)
RealTimeIsUniversal (REG_DWORD) = 0x00000001 (1)
StandardBias (REG_DWORD) = 0x00000000 (0)
StandardName (REG_SZ) = "@tzres.dll,-192"
StandardStart (REG_BINARY) = 00 00 0b 00 01 00 02 00
TimeZoneKeyName (REG_SZ) = "Mountain Standard Time"

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
     Bias    REG_DWORD    0x1a4
     DaylightBias    REG_DWORD    0xffffffc4
     DaylightName    REG_SZ    @tzres.dll,-191
     DaylightStart    REG_BINARY    00000300020002000000000000000000
     DynamicDaylightTimeDisabled    REG_DWORD    0x0
     RealTimeIsUniversal    REG_DWORD    0x1
     StandardBias    REG_DWORD    0x0
     StandardName    REG_SZ    @tzres.dll,-192
     StandardStart    REG_BINARY    00000B00010002000000000000000000
     TimeZoneKeyName    REG_SZ    Mountain Standard Time


HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Time Zones/Mountain 
Standard Time
Dynamic DST\ ()
Display (REG_SZ) = "(UTC-07:00) Mountain Time (US & Canada)"
Dlt (REG_SZ) = "Mountain Summer Time"
MUI_Display (REG_SZ) = "@tzres.dll,-190"
MUI_Dlt (REG_SZ) = "@tzres.dll,-191"
MUI_Std (REG_SZ) = "@tzres.dll,-192"
Std (REG_SZ) = "Mountain Standard Time"
TZI (REG_BINARY) = a4 01 00 00 00 00 00 00

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time 
Zones\Mountain Standard Time
     Display    REG_SZ    (UTC-07:00) Mountain Time (US & Canada)
     Dlt    REG_SZ    Mountain Summer Time
     MUI_Display    REG_SZ    @tzres.dll,-190
     MUI_Dlt    REG_SZ    @tzres.dll,-191
     MUI_Std    REG_SZ    @tzres.dll,-192
     Std    REG_SZ    Mountain Standard Time
     TZI    REG_BINARY 
A401000000000000C4FFFFFF00000B0000000100020000000000000000000300000002000200000000000000

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time 
Zones\Mountain Standard Time\Dynamic DST
     2006    REG_BINARY 
A401000000000000C4FFFFFF00000A0000000500020000000000000000000400000001000200000000000000
     2007    REG_BINARY 
A401000000000000C4FFFFFF00000B0000000100020000000000000000000300000002000200000000000000
     FirstEntry    REG_DWORD    0x7d6
     LastEntry    REG_DWORD    0x7d7


HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Time Zones/Mountain 
Standard Time/Dynamic DST
2006 (REG_BINARY) = a4 01 00 00 00 00 00 00
2007 (REG_BINARY) = a4 01 00 00 00 00 00 00
FirstEntry (REG_DWORD) = 0x000007d6 (2006)
LastEntry (REG_DWORD) = 0x000007d7 (2007)

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time 
Zones\Mountain Standard Time\Dynamic DST
     2006    REG_BINARY 
A401000000000000C4FFFFFF00000A0000000500020000000000000000000400000001000200000000000000
     2007    REG_BINARY 
A401000000000000C4FFFFFF00000B0000000100020000000000000000000300000002000200000000000000
     FirstEntry    REG_DWORD    0x7d6
     LastEntry    REG_DWORD    0x7d7


# dump of Morocco Dynamic DST
$ reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time 
Zones\Morocco Standard Time\Dynamic DST" /s

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time 
Zones\Morocco Standard Time\Dynamic DST
     2007    REG_BINARY 
0000000000000000C4FFFFFF0000000000000000000000000000000000000000000000000000000000000000
     2008    REG_BINARY 
0000000000000000C4FFFFFF000008000000050017003B003B00E703000005000600050017003B003B00E703
     2009    REG_BINARY 
0000000000000000C4FFFFFF000008000400030017003B003B00E703000005000000050017003B003B00E703
     2010    REG_BINARY 
0000000000000000C4FFFFFF000008000600010017003B003B00E703000005000600010017003B003B00E703
     2011    REG_BINARY 
0000000000000000C4FFFFFF000007000600050017003B003B00E703000004000600010017003B003B00E703
     2012    REG_BINARY 
0000000000000000C4FFFFFF0000090000000500030000000000000000000400000005000200000000000000
     2013    REG_BINARY 
0000000000000000C4FFFFFF00000A0000000500030000000000000000000400000005000200000000000000
     2014    REG_BINARY 
0000000000000000C4FFFFFF00000A0000000500030000000000000000000300000005000200000000000000
     2015    REG_BINARY 
0000000000000000C4FFFFFF00000A0000000500030000000000000000000300000005000200000000000000
     2016    REG_BINARY 
0000000000000000C4FFFFFF00000A0000000500030000000000000000000300000005000200000000000000
     2017    REG_BINARY 
0000000000000000C4FFFFFF00000A0000000500030000000000000000000300000005000200000000000000
     FirstEntry    REG_DWORD    0x7d7
     LastEntry    REG_DWORD    0x7ed
     2020    REG_BINARY 
0000000000000000C4FFFFFF0000040000000300030000000000000000000500000005000200000000000000
     2021    REG_BINARY 
0000000000000000C4FFFFFF0000040000000200030000000000000000000500000003000200000000000000
     2022    REG_BINARY 
0000000000000000C4FFFFFF0000030000000500030000000000000000000500000002000200000000000000
     2023    REG_BINARY 
0000000000000000C4FFFFFF0000030000000300030000000000000000000400000004000200000000000000
     2024    REG_BINARY 
0000000000000000C4FFFFFF0000030000000200030000000000000000000400000002000200000000000000
     2025    REG_BINARY 
0000000000000000C4FFFFFF0000020000000500030000000000000000000400000001000200000000000000
     2026    REG_BINARY 
0000000000000000C4FFFFFF0000020000000300030000000000000000000300000004000200000000000000
     2027    REG_BINARY 
0000000000000000C4FFFFFF0000020000000100030000000000000000000300000002000200000000000000
     2028    REG_BINARY 
0000000000000000C4FFFFFF0000010000000400030000000000000000000300000001000200000000000000
     2029    REG_BINARY 
0000000000000000C4FFFFFF0000010000000200030000000000000000000200000003000200000000000000
     2018    REG_BINARY 
0000000000000000C4FFFFFF00000A0000000400030000000000000000000300000004000200000000000000
     2019    REG_BINARY 
0000000000000000C4FFFFFF0000010002000100000000000000000000000600000002000200000000000000
]

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

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

[Ken Brown]

On 6/12/2021 12:34 PM, Brian Inglis wrote:
> On 2021-06-11 12:05, Ken Brown via Cygwin wrote:
>> On 6/11/2021 1:33 PM, Brian Inglis wrote:
>>> On 2021-06-10 13:50, Ken Brown via Cygwin wrote:
>>>> On 6/10/2021 2:31 PM, Brian Inglis wrote:
>>>>> On 2021-06-10 08:57, Ken Brown via Cygwin wrote:
>>>>>> On 6/9/2021 10:36 PM, Brian Inglis wrote:
>>>>>>> On 2021-06-09 16:31, Keith Thompson via Cygwin wrote:
>>>>>>>> [Sorry if the threading is messed up.  I don't subscribe, so I'm
>>>>>>>> constructing this message from the web interface.  It should at least
>>>>>>>> show up under the correct subject.]
>>>>>>>>
>>>>>>>> Brian Inglis wrote:
>>>>>>>>> On 2021-06-08 14:03, Mike Kaganski via Cygwin wrote:
>>>>>>>>>> On 08.06.2021 16:04, L A Walsh wrote:
>>>>>>>>>>> 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?
>>>>>>>>>>
>>>>>>>>>> FTR: filed https://bugs.python.org/issue44352.
>>>>>>>>>
>>>>>>>>> See Keith Thompson subthread and my reply with suggested fix:
>>>>>>>>>
>>>>>>>>> https://cygwin.com/pipermail/cygwin/2021-June/248692.html
>>>>>>>>>
>>>>>>>>> Windows does not recognize zoneinfo time zone identifiers in TZ only
>>>>>>>>> base format POSIX TZ strings with three alphabetic character identifiers:
>>>>>>>>>
>>>>>>>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-160 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That assumes US switch date "rules": for all years up to current, or
>>>>>>>>> just DST, and whether pre- or post-2007 is unstated!
>>>>>>>>>
>>>>>>>>> Otherwise it defaults to regional settings, used by Cygwin to map to
>>>>>>>>> zoneinfo time zone identifiers, so if Python for Windows could clear TZ
>>>>>>>>> before it is read by MSVCRT, it should DTRT.
>>>>>>>>>
>>>>>>>>> Windows does not recognize expanded POSIX TZ format strings with <>
>>>>>>>>> quoted alphanumeric characters, "-", "+", and start and end dates/times:
>>>>>>>>>
>>>>>>>>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#bottom 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> which make them usable outside of the US.
>>>>>>>>
>>>>>>>> Summary: IMHO Cygwin should adapt its default TZ setting to work
>>>>>>>> with Windows.
>>>>>>>>
>>>>>>>> The suggestion is to modify Python for Windows so it can deal with
>>>>>>>> the TZ format used by Cygwin.  I haven't used Python for Windows, but
>>>>>>>> as far as I know it's unrelated to Cygwin; rather it, like Cygwin, is
>>>>>>>> intended to work on top of Windows.  I'm not convinced it's appropriate
>>>>>>>> to ask Python for Windows to make a change purely for the sake of
>>>>>>>> interoperating with Cygwin, which many PfW users presumably aren't
>>>>>>>> even using.
>>>>>>>>
>>>>>>>> I've run into another application that has problems with Cygwin's
>>>>>>>> settings of $TZ.  It was a internal test application that isn't
>>>>>>>> going to change its timezone handling just for this problem.
>>>>>>>>
>>>>>>>> The ideal solution would be for Windows to recognize TZ values like
>>>>>>>> "America/Los_Angeles", but that's not likely to happen any time soon.
>>>>>>>>
>>>>>>>> My suggestion, since Cygwin is supposed to interoperate with Windows,
>>>>>>>> is one of the following:
>>>>>>>>
>>>>>>>> - Cygwin should avoid setting TZ to a value that Windows doesn't recognize
>>>>>>>>    (if I set TZ=PST8PDT, everything seems to work correctly); OR
>>>>>>>>
>>>>>>>> - Cygwin shouldn't set TZ at all by default.  (I've updated my
>>>>>>>>    $HOME/.bash_profile on Cygwin to unset TZ, and Cygwin commands seem
>>>>>>>>    to work correctly with TZ unset); OR
>>>>>>>>
>>>>>>>> - Cygwin, when invoking a non-Cygwin executable, should first either
>>>>>>>>    unset TZ or translate it to a format that Windows will recognize.
>>>>>>>>    I have no idea how difficult that would be.
>>>>>>>
>>>>>>> Impossible to set Windows TZ usefully as it obeys unstated US DST rules 
>>>>>>> (like posixrules, perhaps 2007+?), and may have limits on hour offset 
>>>>>>> magnitudes.
>>>>>>> MS libraries are stuck at POSIX 1996 and C 99 subset compatibility, but 
>>>>>>> non-standard-conformant including which headers contain definitions:
>>>>>>>
>>>>>>>      https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility?view=msvc-160 
>>>>>>>
>>>>>>>
>>>>>>> It may be possible to unset TZ when running non-Cygwin programs (possibly 
>>>>>>> behind a CYGWIN env var setting e.g. winnotz) by adding TZ= to 
>>>>>>> conv_envvars, and writing new helper functions env_tz_to_posix to call 
>>>>>>> tzset and env_tz_to_win32 to remove TZ in:
>>>>>>>
>>>>>>>      https://sourceware.org/git/?p=newlib-cygwin.git;f=winsup/cygwin/environ.cc;a=blob 
>>>>>>>
>>>>>>>
>>>>>>> What is the opinion on this from both Windows users and Cygwin patchers?
>>>>>>
>>>>>> I'm not convinced it's worth the trouble.  I haven't seen anyone argue 
>>>>>> that it's useful for Cygwin to set TZ, and I have seen an argument that 
>>>>>> it's harmful:
>>>>>>
>>>>>>    https://cygwin.com/pipermail/cygwin/2017-May/232675.html .
>>>>>>
>>>>>> So I prefer Keith's second suggestion:
>>>>>>
>>>>>>  >> - Cygwin shouldn't set TZ at all by default.
>>>>>
>>>>> It does so in default startup scripts
>>>>
>>>> Right, and I'm agreeing with Bruno (in the message cited above) that the 
>>>> default startup scripts should stop doing that.
>>>>
>>>>> to get the correct behaviour from Cygwin DLL and programs,
>>>>
>>>> Can you be more specific?  What goes wrong if TZ is not set?  I haven't seen 
>>>> any POSIX or Linux documentation that says it should be set, and I've just 
>>>> checked on two different Linux distros that it's not set by default.
> 
> See original message:
> 
>      https://sourceware.org/pipermail/cygwin/2012-January/199548.html
> 
> Looks like the tzdb metadata is not fully populated, including zone 
> abbreviations, though that could be patched to use <%z> like tzdata defaults 
> where countries use only a single local time zone and no name (other than 
> COUNTRY time, and maybe Winter Time or Summer Time, as in many European countries).
> 
>>> I would expect that date, ls, etc. would output UTC, or perhaps PST or EST, 
>>> depending on tzdata builds of Factory (tz -00/unset) and posixrules (Cygwin 
>>> PST, Debian EST) and use during system setup and startup, unless 
>>> /etc/timezone and/or /etc/localtime are set, and used during startup, often 
>>> by systemd, or login by profiles.
>>
>> No, you can 'unset TZ' and everything works fine.  Try it yourself.
> 
> It works incorrectly before 2007 because of DST rule changes.
 > [...]

You obviously know much more about this than I do.  I'm going to drop out of 
this discussion and leave it to people who know what they're talking about.

Ken

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

[Andrey Repin]

Greetings, Brian Inglis!

> On 2021-06-09 16:31, Keith Thompson via Cygwin wrote:
>> [Sorry if the threading is messed up.  I don't subscribe, so I'm
>> constructing this message from the web interface.  It should at least
>> show up under the correct subject.]

You can always reply to your own message sent to the list in an appropriate
thread.
Nobody's linking by subject, that was frowned upon 25 years ago, and just
ridiculous in XXI century.

>> 
>> Brian Inglis wrote:
>>> On 2021-06-08 14:03, Mike Kaganski via Cygwin wrote:
>>>> On 08.06.2021 16:04, L A Walsh wrote:
>>>>> 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?
>>>>
>>>> FTR: filed https://bugs.python.org/issue44352.
>>>
>>> See Keith Thompson subthread and my reply with suggested fix:
>>>
>>> https://cygwin.com/pipermail/cygwin/2021-June/248692.html
>>>
>>> Windows does not recognize zoneinfo time zone identifiers in TZ only
>>> base format POSIX TZ strings with three alphabetic character identifiers:
>>>
>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-160
>>>
>>> That assumes US switch date "rules": for all years up to current, or
>>> just DST, and whether pre- or post-2007 is unstated!
>>>
>>> Otherwise it defaults to regional settings, used by Cygwin to map to
>>> zoneinfo time zone identifiers, so if Python for Windows could clear TZ
>>> before it is read by MSVCRT, it should DTRT.
>>>
>>> Windows does not recognize expanded POSIX TZ format strings with <>
>>> quoted alphanumeric characters, "-", "+", and start and end dates/times:
>>>
>>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#bottom
>>>
>>> which make them usable outside of the US.
>> 
>> Summary: IMHO Cygwin should adapt its default TZ setting to work
>> with Windows.

Windows programs generally ignore TZ env var at all to begin with.

>> The suggestion is to modify Python for Windows so it can deal with
>> the TZ format used by Cygwin.  I haven't used Python for Windows, but
>> as far as I know it's unrelated to Cygwin; rather it, like Cygwin, is
>> intended to work on top of Windows.  I'm not convinced it's appropriate
>> to ask Python for Windows to make a change purely for the sake of
>> interoperating with Cygwin, which many PfW users presumably aren't
>> even using.
>> 
>> I've run into another application that has problems with Cygwin's
>> settings of $TZ.  It was a internal test application that isn't
>> going to change its timezone handling just for this problem.
>> 
>> The ideal solution would be for Windows to recognize TZ values like
>> "America/Los_Angeles", but that's not likely to happen any time soon.
>> 
>> My suggestion, since Cygwin is supposed to interoperate with Windows,
>> is one of the following:
>> 
>> - Cygwin should avoid setting TZ to a value that Windows doesn't recognize
>>    (if I set TZ=PST8PDT, everything seems to work correctly); OR
>> 
>> - Cygwin shouldn't set TZ at all by default.  (I've updated my
>>    $HOME/.bash_profile on Cygwin to unset TZ, and Cygwin commands seem
>>    to work correctly with TZ unset); OR
>> 
>> - Cygwin, when invoking a non-Cygwin executable, should first either
>>    unset TZ or translate it to a format that Windows will recognize.
>>    I have no idea how difficult that would be.

> Impossible to set Windows TZ usefully as it obeys unstated US DST rules 
> (like posixrules, perhaps 2007+?), and may have limits on hour offset 
> magnitudes.
> MS libraries are stuck at POSIX 1996 and C 99 subset compatibility, but 
> non-standard-conformant including which headers contain definitions:

>        
> https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility?view=msvc-160

> It may be possible to unset TZ when running non-Cygwin programs 
> (possibly behind a CYGWIN env var setting e.g. winnotz) by adding TZ= to 
> conv_envvars, and writing new helper functions env_tz_to_posix to call 
> tzset and env_tz_to_win32 to remove TZ in:

>        
> https://sourceware.org/git/?p=newlib-cygwin.git;f=winsup/cygwin/environ.cc;a=blob

> What is the opinion on this from both Windows users and Cygwin patchers?

I would wish to avoid unexpected environment modification.
If anything, when you want to frequently call Windows programs from within
Cygwin, you could always create symlink or an appropriate wrapper in
/usr/local/bin.

I.e.
$ ls -ld /usr/local/bin/* | cut -f 7-
/usr/local/bin/adb -> /c/Programs/MyPhoneExplorer/DLL/adb.exe
/usr/local/bin/chcp -> /c/Windows/System32/chcp.com (since Cygwin magic only works with .exe)
/usr/local/bin/git-agent.sh (force read of ssh-agent settings before calling git)
/usr/local/bin/ip (*NIX compatibility wrapper around netsh)
/usr/local/bin/meld -> /c/Program Files (x86)/Meld/Meld.exe
/usr/local/bin/svn1.6 -> /c/Programs/Subversion/bin/svn.exe
/usr/local/bin/tasklist
/usr/local/bin/tcc (wrapper around TakeCommandConsole)
/usr/local/bin/vscode -> /c/Program Files/Microsoft VS Code/bin/code (vendor-provided wrapper)

> [I am one of those folks who like maximum POSIX/Linux compatibility from 
> my environment and scripts, so maintain files/sym-/links like /run, 
> /etc/timezone, /etc/localtime from local 0p_/zp_ postinstall scripts.]

If TZ is not all-useful for Cygwin, I would vote to not have it set at all.


-- 
With best regards,
Andrey Repin
Friday, June 11, 2021 12:22:26

Sorry for my terrible english...

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

[Mike Kaganski]

Hello,

Running Cygwin 3.1.7-1 on Windows 10 Version 21H1 (OS Build 19043.985), 
I have this issue:

when I start Cygwin's Python, I have correct time reported:

> mikek@DESKTOP-8SHAE9Q ~
> $ python
> Python 3.8.9 (default, Apr 21 2021, 23:14:29)
> [GCC 10.2.0] on cygwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import datetime
> >>> datetime.datetime.now()
> datetime.datetime(2021, 6, 7, 9, 40, 15, 318391)

But running Python for Windows (it doesn't matter which, specifically 
for the test I used the one from MS Store [1]), I have incorrect local time:

> mikek@DESKTOP-8SHAE9Q ~
> $ "C:/Program 
> Files/WindowsApps/PythonSoftwareFoundation.Python.3.8_3.8.2800.0_x64__qbz5n2kfra8p0/python3.8.exe"
> Python 3.8.10 (tags/v3.8.10:3d8993a, May  3 2021, 11:48:03) [MSC 
> v.1928 64 bit (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import datetime
> >>> datetime.datetime.now()
> datetime.datetime(2021, 6, 7, 7, 40, 55, 503775)

Note how the latter output reports 2021-06-07 07:40, while the former 
reports 2021-06-07 09:40. The difference is 2 hours.

Starting the same Python for Windows from cmd.exe has it correct:

> C:\Users\mikek>python
> Python 3.8.10 (tags/v3.8.10:3d8993a, May  3 2021, 11:48:03) [MSC 
> v.1928 64 bit (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import datetime
> >>> datetime.datetime.now()
> datetime.datetime(2021, 6, 7, 9, 41, 21, 925240)

Cygwin reports correct timezone:

> $ echo $TZ
> Europe/Moscow

Starting Python for Windows using a different timezone (specifically, '$ 
TZ=UTC "C:/Program 
Files/WindowsApps/PythonSoftwareFoundation.Python.3.8_3.8.2800.0_x64__qbz5n2kfra8p0/python3.8.exe"') 
gives correct time for *that* time zone.

This is a problem, because in our project (LibreOffice), we use Cygwin 
as environment for unit testing, where LibreOffice's own Python (also 
built natively for Windows) is used, and at some times (from 00:00 till 
02:00) it reports wrong dates, which makes tests fail locally on 
affected systems(see [2]).

Thank you!


[1] https://www.microsoft.com/en-us/p/python-38/9mssztt1n39l

[2] 
https://gerrit.libreoffice.org/c/core/+/92217/2#message-f55091795e7cde9d75adc00ddb69451121b644f6


-- 

Best regards,

Mike Kaganski

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

[Russell VT]

What version(s) of the timezone files are installed on each?

Also, seems one of the Python versions came from Windows, rather than
Cygwin?



On Mon, Jun 7, 2021 at 12:01 AM Mike Kaganski via Cygwin <cygwin@cygwin.com>
wrote:

> Hello,
>
> Running Cygwin 3.1.7-1 on Windows 10 Version 21H1 (OS Build 19043.985),
> I have this issue:
>
> when I start Cygwin's Python, I have correct time reported:
>
> > mikek@DESKTOP-8SHAE9Q ~
> > $ python
> > Python 3.8.9 (default, Apr 21 2021, 23:14:29)
> > [GCC 10.2.0] on cygwin
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import datetime
> > >>> datetime.datetime.now()
> > datetime.datetime(2021, 6, 7, 9, 40, 15, 318391)
>
> But running Python for Windows (it doesn't matter which, specifically
> for the test I used the one from MS Store [1]), I have incorrect local
> time:
>
> > mikek@DESKTOP-8SHAE9Q ~
> > $ "C:/Program
> >
> Files/WindowsApps/PythonSoftwareFoundation.Python.3.8_3.8.2800.0_x64__qbz5n2kfra8p0/python3.8.exe"
> > Python 3.8.10 (tags/v3.8.10:3d8993a, May  3 2021, 11:48:03) [MSC
> > v.1928 64 bit (AMD64)] on win32
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import datetime
> > >>> datetime.datetime.now()
> > datetime.datetime(2021, 6, 7, 7, 40, 55, 503775)
>
> Note how the latter output reports 2021-06-07 07:40, while the former
> reports 2021-06-07 09:40. The difference is 2 hours.
>
> Starting the same Python for Windows from cmd.exe has it correct:
>
> > C:\Users\mikek>python
> > Python 3.8.10 (tags/v3.8.10:3d8993a, May  3 2021, 11:48:03) [MSC
> > v.1928 64 bit (AMD64)] on win32
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import datetime
> > >>> datetime.datetime.now()
> > datetime.datetime(2021, 6, 7, 9, 41, 21, 925240)
>
> Cygwin reports correct timezone:
>
> > $ echo $TZ
> > Europe/Moscow
>
> Starting Python for Windows using a different timezone (specifically, '$
> TZ=UTC "C:/Program
> Files/WindowsApps/PythonSoftwareFoundation.Python.3.8_3.8.2800.0_x64__qbz5n2kfra8p0/python3.8.exe"')
>
> gives correct time for *that* time zone.
>
> This is a problem, because in our project (LibreOffice), we use Cygwin
> as environment for unit testing, where LibreOffice's own Python (also
> built natively for Windows) is used, and at some times (from 00:00 till
> 02:00) it reports wrong dates, which makes tests fail locally on
> affected systems(see [2]).
>
> Thank you!
>
>
> [1] https://www.microsoft.com/en-us/p/python-38/9mssztt1n39l
>
> [2]
>
> https://gerrit.libreoffice.org/c/core/+/92217/2#message-f55091795e7cde9d75adc00ddb69451121b644f6
>
>
> --
>
> Best regards,
>
> Mike Kaganski
>
>
> --
> Problem reports:      https://cygwin.com/problems.html
> FAQ:                  https://cygwin.com/faq/
> Documentation:        https://cygwin.com/docs.html
> Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
>


-- 
Russell M. Van Tassell <russellvt@gmail.com>

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

[Mike Kaganski]

On 08.06.2021 7:34, Russell VT wrote:
> What version(s) of the timezone files are installed on each?

Cygwin:

> $ cygcheck -c | grep tz
> tzcode 2021a-1                         OK
> tzdata 2021a-1                         OK

Windows:

I didn't find a TZ-specific update KB in the list of installed updates. 
However, I did check that there is a "(UTC+2:00) Juba" timezone in the 
Windows selector, as described in [1], which means that the respective 
TZ update (also described in KB4601275) is present on system.

>
> Also, seems one of the Python versions came from Windows, rather than 
> Cygwin?

Heh, I hoped that when I titled the original mail as "Python *for 
Windows* reports ... under Cygwin ...", and repeatedly mentioned that in 
the body, it's obvious that indeed, the problem is exactly running 
native Windows build of Python under cygwin:

>
>     But running Python *for Windows* (it doesn't matter which,
>     specifically
>     for the test I used the one *from MS Store* [1]), I have incorrect
>     local time:
>     ...
>     Starting the same Python *for Windows* from cmd.exe has it correct:
>     ...
>     This is a problem, because in our project (LibreOffice), we use
>     Cygwin
>     as environment for unit testing, where LibreOffice's own Python (also
>     *built natively for Windows*) is used, and at some times ...
>

[1] 
https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/2021-time-zone-updates-for-republic-of-south-sudan-now-available/ba-p/2234981


-- 

Best regards,

Mike Kaganski

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

[L A Walsh]

On 2021/06/06 23:59, Mike Kaganski via Cygwin wrote:
> Hello,
>
> Running Cygwin 3.1.7-1 on Windows 10 Version 21H1 (OS Build 
> 19043.985), I have this issue:
>
> when I start Cygwin's Python, I have correct time reported:
>
> But running Python for Windows (it doesn't matter which, specifically 
> for the test I used the one from MS Store [1]), I have incorrect local 
> time

Why are you reporting a problem in Windows-Python on a cygwin
list, especially when the cygwin python runs correctly?  Admittedly
I'd be more interested to know what happened in perl, but doubt
MS wants to try supporting that can of worms.

I don't see it as a bug, really, but another Win10 feature!
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.

Anyway, I assume you reported it here just to amuse cygwin users
at MS's Win-Python?  ;-)

Long live my buggy Win7!  ;-)

It's so funny -- bugs that I had for 6-7 years in Win7, they finally
told me would be fixed in Win10.  But recently, saw the same bug/prob
being reported in Win10 -- and MS still doesn't know the problem.

So checked a some settings and found out how to fix it on Win7,
but only

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

[Mike Kaganski]

On 08.06.2021 14:37, L A Walsh wrote:
> On 2021/06/06 23:59, Mike Kaganski via Cygwin wrote:
>> Hello,
>>
>> Running Cygwin 3.1.7-1 on Windows 10 Version 21H1 (OS Build 
>> 19043.985), I have this issue:
>>
>> when I start Cygwin's Python, I have correct time reported:
>>
>> But running Python for Windows (it doesn't matter which, specifically 
>> for the test I used the one from MS Store [1]), I have incorrect 
>> local time
>
> Why are you reporting a problem in Windows-Python on a cygwin
> list, especially when the cygwin python runs correctly? Admittedly
> I'd be more interested to know what happened in perl, but doubt
> MS wants to try supporting that can of worms.
>
> ...
>
> Anyway, I assume you reported it here just to amuse cygwin users
> at MS's Win-Python?  ;-)

No, I report a problem that a native program runs incorrectly *under 
Cygwin*, because Cygwin is indeed part of the picture, 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. 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.

> 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.


-- 

Best regards,

Mike Kaganski

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

[L A Walsh]

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

> 
> 

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

[Mike Kaganski]

On 08.06.2021 16:04, L A Walsh wrote:
> 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.

First of all - please stop telling me that I required support. I didn't 
demand anything, and was asking *in the hope*, but without any wrong 
expectations that anyone owes anything here. I never claimed that 
someone must support my use case - so please, please stop answering what 
wasn't said. I am a free software developer, working on LibreOffice 
project; I know what free software is, and what mailing list is. That 
they don't support something doesn't mean it's inappropriate to ask with 
a hope, a question that could be *possibly* answered, and which answer 
could happen to be helpful also to others.

>     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.

See above.

>> 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.

MS didn't. The native Windows builds of Python weren't from MS - they 
were from LibreOffice and from Python Software Foundation, as described 
in the initial mail (and at the sites linked there).

>     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?

I will ask at Python, of course. I didn't yet, because I didn't want to 
cross-post same question to many places, and am waiting until it's clear 
that I need to ask there, not here.

>
>> 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.

See above.

>
>>
>>> 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 mean "start Cygwin terminal - either C:\cygwin64\bin\mintty.exe, or 
C:\cygwin64\Cygwin.bat; then start Python using a command line as 
provided in the initial mail - I have provided there a full command line 
with the path".

>   ... 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.

I will try without TZ.

> 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

Indeed there's no Cygwin's DLLs reported.


-- 

Best regards,

Mike Kaganski

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

[L A Walsh]

On 2021/06/08 06:30, Mike Kaganski wrote:

> First of all - please stop telling me that I required support. I didn't 
> demand anything, and was asking *in the hope*, but without any wrong 
> expectations that anyone owes anything here. 
---

	Have you ever heard the statement "asking is polite
demanding."?   I've had lots of people tell me that for similar
reasons.  Don't stress this I really find more of this as humorous than
anything critical.


> I never claimed that 
> someone must support my use case - so please, please stop answering what 
> wasn't said.
---
	You didn't claim, you asked.  Also you asserted that your
python didn't work because of cygwin in the mix.  I'm not a cygwin
developer, but have used it for over 20 years.  I spoke up because
I am a computer scientist and the way you were describing the problem
was a bit on the amusing side, only because of the logic involved.

I am a free software developer, working on LibreOffice 
> project;
----
	congrats...I've never really gotten that far because i'm
too picky, and easily distractable among other reasons.

> That ... doesn't mean it's inappropriate to ask with 
> a hope, a question that could be *possibly* answered, and which answer 
> could happen to be helpful also to others.
---
	I know, I do it frequently, and am accused of waisting other
people's time for my work.  Unfortunately, it's a dynamic that is
hard for some people to deal with.

> The cygwin devs can't
>> support all the 3rd party programs that interfere.
> 
> See above.
---
	You aren't getting that answering questions *IS* a form
of support.  For better or worse, most companies now hire
3rd party companies to do support who know nothing about the product.
They just ask general questions and keep having you do random 
maintenance and diagnostic tasks until something pops out that 
may answer the question, but more often until the customer is
discouraged enough to stop answering back.

	I took an issue to its final conclusion one time -- about
45 days of back and forth with them asking me to do various random
tasks and run 3rd party progs -- but none of them in support knew
anything about the product or the servers or the hardware -- they
weren't allowed to know -- they were there as a buffer, to keep
the users away from the developers!  That's how most companies operate
these days -- Google, Microsoft, NVidia, all the major game companies.
Like a call into nvidia where it doesn't install a driver for two
items.  I contacted nvidia and their support person couldn't answer
the question.  Instead, they put the problem on me because I was still
running Win7 and couldn't generate an activeX diag, but I could
run their own card diag -- but they focused on the activeX diag.
I countered with the fact that the two unknown devices are listed
as being attached to the video card.  Can't they look at a hardware
spec and tell me what is connected there?  They stopped responding.

	Like a previous issue, no doubt, it will stay open 
for ever in the "doing research state"....

	Anyway, I'm way off your original topic, but I hope I
at least gave you a few pointers -- even if you did think I was
criticizing, oh well...

	But I did what the 3rd party support people did and led you
along more generic ways of looking for the prob even though I know
little about cygwin internals.  Anyway, see you found a workaround,
so fab & have fun!

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

[Mike Kaganski]

On 08.06.2021 16:57, L A Walsh wrote:
>     You aren't getting that answering questions *IS* a form
> of support.

LOL. Please see how I do this support: https://ask.libreoffice.org/en/users/

I know it all. I answer others' questions. What I was talking about was 
that I didn't demand, and didn't expect anyone obliged. Volunteer 
support is - as you might guess - volunteer; if some entity runs a 
public mailing list, it's reasonable to expect questions like this on 
that list; so any "answers" like yours "why do you ask here" are 
off-topic. If one believes that person doesn't want to answer, it's 
better to just not answer, then claim that the question is inappropriate.

Anyways, thank you again for the hint that helped me to workaround the 
problem - unsetting the TZ.


-- 

Best regards,

Mike Kaganski.

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

[L A Walsh]

On 2021/06/08 07:10, Mike Kaganski wrote:
> so any "answers" like yours "why do you ask here" are 
> off-topic.
---
But what most people dont' see -- I didn't say you *shouldn't*
post here, I asked why when the evidence suggested the problem
was python reading TZ info from 2 sources -- like config files
and ENV.  Honestly I wasn't saying you shouldn't have asked
here, just questioning your logic/reasoning.  

I'm just not very clear on where I'm going in a conversation 
sometimes, as I take a very round-about path, which if taken,
often ends up getting someone to where they want to go, but
certainly not via a str8-line.  *sigh*....

*cheers*

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

[Mike Kaganski]

On 08.06.2021 16:04, L A Walsh wrote:
> Look in its environment and remove any thing for timezone and try that.


Thanks to this great suggestion, I was able to workaround this problem - 
thanks!

Wrong result (using the TZ present in environment, i.e. TZ=Europe/Moscow):

> $ "C:/Program 
> Files/WindowsApps/PythonSoftwareFoundation.Python.3.8_3.8.2800.0_x64__qbz5n2kfra8p0/python3.8.exe"
> Python 3.8.10 (tags/v3.8.10:3d8993a, May  3 2021, 11:48:03) [MSC 
> v.1928 64 bit (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import datetime
> >>> datetime.datetime.now()
> datetime.datetime(2021, 6, 8, 14, 31, 19, 163849)

Compared to call with TZ unset:

> $ TZ= "C:/Program 
> Files/WindowsApps/PythonSoftwareFoundation.Python.3.8_3.8.2800.0_x64__qbz5n2kfra8p0/python3.8.exe"
> Python 3.8.10 (tags/v3.8.10:3d8993a, May  3 2021, 11:48:03) [MSC 
> v.1928 64 bit (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import datetime
> >>> datetime.datetime.now()
> datetime.datetime(2021, 6, 8, 16, 32, 13, 605201)


Thank you again! This is enough workaround for now. I somehow overlooked 
it, when tried with TZ set to UTC. Shame on me :-)


-- 

Best regards,

Mike Kaganski

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

[Mike Kaganski]

On 08.06.2021 16:04, L A Walsh wrote:
> 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? 

FTR: filed https://bugs.python.org/issue44352.


-- 

Best regards,

Mike Kaganski

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

[Brian Inglis]

On 2021-06-08 14:03, Mike Kaganski via Cygwin wrote:
> On 08.06.2021 16:04, L A Walsh wrote:
>> 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? 
> 
> FTR: filed https://bugs.python.org/issue44352.

See Keith Thompson subthread and my reply with suggested fix:

	https://cygwin.com/pipermail/cygwin/2021-June/248692.html

Windows does not recognize zoneinfo time zone identifiers in TZ only 
base format POSIX TZ strings with three alphabetic character identifiers:

	https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-160

That assumes US switch date "rules": for all years up to current, or 
just DST, and whether pre- or post-2007 is unstated!

Otherwise it defaults to regional settings, used by Cygwin to map to 
zoneinfo time zone identifiers, so if Python for Windows could clear TZ 
before it is read by MSVCRT, it should DTRT.

Windows does not recognize expanded POSIX TZ format strings with <> 
quoted alphanumeric characters, "-", "+", and start and end dates/times:

	https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#bottom

which make them usable outside of the US.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

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

[Mike Kaganski]

On 08.06.2021 14:37, L A Walsh wrote:
> On 2021/06/06 23:59, Mike Kaganski via Cygwin wrote:
>> Hello,
>>
>> Running Cygwin 3.1.7-1 on Windows 10 Version 21H1 (OS Build 
>> 19043.985), I have this issue:
>>
>> when I start Cygwin's Python, I have correct time reported:
>>
>> But running Python for Windows (it doesn't matter which, specifically 
>> for the test I used the one from MS Store [1]), I have incorrect 
>> local time
>
> ...
>
> 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.

As described in Python's issue [1], the problem comes from passing a TZ 
environment variable value that is invalid for Windows C runtime [2]. So 
in the end, it *might* be something for Cygwin to handle.

*If* Cygwin can detect that it starts a native Windows binary (I hope it 
can), then it could try to convert the TZ from Unix kind to Windows 
kind. That way, it could become valid. Or at least it could be unset 
(but that is questionable).

Of course, I could overlook some possible drawbacks from this imagined 
fix, which could make it undesirable. Anyway, I have implemented a 
workaround in our project unsetting TZ before calling Python, and it's 
resolved for us.

Thanks!


[1] https://bugs.python.org/issue44352

[2] 
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-160


-- 

Best regards,

Mike Kaganski