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