From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-developers@cygwin.com
Subject: Re: tzcode resync
Date: Wed, 29 Apr 2020 11:31:26 +0200 [thread overview]
Message-ID: <20200429093126.GF4499@calimero.vinschen.de> (raw)
In-Reply-To: <Pine.BSF.4.63.2004290159330.49183@m0.truegem.net>
On Apr 29 02:05, Mark Geisert wrote:
> On Wed, 29 Apr 2020, Corinna Vinschen wrote:
> > On Apr 29 00:03, Mark Geisert wrote:
> > > On Mon, 27 Apr 2020, Corinna Vinschen wrote:
> > > > On Apr 24 17:19, Yaakov Selkowitz wrote:
> > > > > Our winsup/cygwin/localtime.cc is a mashup of a very old version of
> > > > > upstream tzcode's private.h, tzfile.h, and localtime.c with Cygwin-
> > > > > specific patches for getting the timezone from windows as a fallback,
> > > > > as well as handling API compatibility with pre-tm_gmtoff binaries.
> > > > >
> > > > > The upstream tzcode/tzdata have introduced database changes which
> > > > > cannot be read by old code. Currently, I am building tzdata in the old
> > > > > ("rearguard") format to keep compatibility, but at this point we're
> > > > > *way* behind upstream and we really should update our code. Given how
> > > > > long it's been though, it's going to be a bit of work.
> > > > [...]
> > > I can take this on. I've looked at the current NetBSD code diffed against
> > > the version we use: there's a fair amount of prototype rejiggering and
> > > recoding of localized areas. New code too, of course. I've done this kind
> > > of thing before and this project seems doable to me.
> >
> > Sounds good to me. I started with this yesterday but didn't make a lot
> > of progress, see below. I'd be happy if you like to take over.
>
> Yes, please :-).
> [...]
> > [...]
> > Cygwin has a builtin binary representation of the file "posixrules" in
> > tz_posixrules.h. Since 2000. And unchanged since 2000!
> >
> > This binary representation is used as posixrules data if the posixrules
> > file doesn't exist or is unreadable. I have a vague feeling that this
> > data is hopelessly outdated and, probably, the format changed as well.
> >
> > So I assume the data in tz_posixrules.h needs either an update, or
> > we drop the inline data entirely.
> >
> > Dropping this inline data shouldn't be much of a problem, right?
> > Cygwin installations shouldn't need it and 3PPs can easily provide
> > a posixrules file, I guess...
> >
> > Mark, Yaakov, what's your stance in terms of this posixrules data?
>
> I think this is an example of the very thing Yaakov mentioned in the quotes
> above. Both this internal backup of posixrules and the usual posixrules
> file in /usr/share/zoneinfo are written in the obsolete Version 0 format.
> The current localtime code can only read this version.
>
> When localtime.cc gets updated, it can read Version 2 (there was no Version
> 1 as far as I can tell). Yaakov will generate V.2 formatted zone files at
> that point.
>
> I can't see a reason to keep this internal backup copy, regardless of which
> Version it is. But if we do need it, we can generate a V.2 version of it
> once localtime.cc is able to read it.
Yeah, I guess that's the way to go. The idea of all this was trying to
make sure a lone Cygwin with an executable would function outside of a
full installation. That's also the reason we have builtin locale data.
How much sense does this make these days...? I don't know. It's just
a safety net for border scenarios.
Corinna
--
Corinna Vinschen
Cygwin Maintainer
prev parent reply other threads:[~2020-04-29 9:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-24 21:19 Yaakov Selkowitz
2020-04-27 8:51 ` Corinna Vinschen
2020-04-29 7:03 ` Mark Geisert
2020-04-29 8:34 ` Corinna Vinschen
2020-04-29 9:05 ` Mark Geisert
2020-04-29 9:31 ` Corinna Vinschen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200429093126.GF4499@calimero.vinschen.de \
--to=corinna-cygwin@cygwin.com \
--cc=cygwin-developers@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).