Re: [PATCH] strbuf: let strbuf_addftime handle %z and %Z itself

From: Jeff King <peff@peff.net>
Date: Jun 12, 2017, 21:10 UTC
Message-ID: <20170612211022.k7t2ywngrdcrkehn@sigill.intra.peff.net>
In-Reply-To: <CACBZZX5OQc45fUyDVayE89rkT=+8m5S4efSXCAbCy7Upme5zLA@mail.gmail.com>

On Mon, Jun 12, 2017 at 09:02:32PM +0200, Ævar Arnfjörð Bjarmason wrote:

Show 10 quoted lines

> > I think the main problem is that the mapping isn't just "JST->+0900".
> > It's a set of rules that depend on the specific time being converted. So
> > it's true that at some time t, +0900 may mean JST or KST or whatever.
> > But at a different time, those time zones will map to a different
> > offset.
> 
> To the extent that it doesn't map correctly (e.g. due to summer time)
> that's already a bug/understood limitation in the fuzzy TZ parser in
> date.c, isn't it (dating back to Linus's "In my world, it's always
> summer" comment in 89967023da).

To be honest, I find that whole timezone_names[] array pretty gross. It gets basic stuff wrong like:

  $ t/helper/test-date parse '2017-02-01 00:00:00 PST8PDT'
  2017-02-01 00:00:00 PST8PDT -> 2017-02-01 00:00:00 -0700

That should be -0800 because it's winter (though the bigger problem is that our parser is too stupid and just sees "PDT" at the end and guesses it's summer).

I suspect nobody has complained because we generally encourage real "-0800" names when specifying zones. Which is really just punting the problem to whoever is generating the timestamp, but it works in practice. And we use real localtime() for handling things in the current zone, which is usually what's responsible for generating any such time. So just using the local zone, both of these are right (notice the zone difference in the summer):

  $ TZ=PST8PDT t/helper/test-date parse '2017-02-01 00:00:00'
  2017-02-01 00:00:00 -> 2017-02-01 00:00:00 -0800

  $ TZ=PST8PDT t/helper/test-date parse '2017-06-01 00:00:00'
  2017-06-01 00:00:00 -> 2017-06-01 00:00:00 -0700

It would be nice to fix that. In theory strptime is the solution, but comments in date.c indicate that it doesn't work well (and I can well believe that). Presumably there is some not-terrible date library out there that really can parse/format in arbitrary time-zones (perl's DateTime is pleasant to use, for example). But I don't know of a C library offhand (and unless we can ship it with the source, I'd guess that the extra dependency isn't worth it).

> I think everyone in this thread disagrees with what I think makes
> sense for %Z, and I'm not going to argue the point, I just thought I'd
> chime in because it seemed to me that the discussion had missed the
> mapping we had in the timezone_names variable.

I did actually forget we had it, though I don't think it changes my opinion.

Show 12 quoted lines

> But FWIW and just to (I think fairly) summarize, here's where we differ.
> 
> You (and others) think that unless we can actually show the user's
> time zone as it appeared on their machine %Z shouldn't show anything
> at all, since it would be confusing. Fair enough.
> 
> I only ever use the time offset info to quickly make a mental note of
> "oh +0200, this guy's in Europe", or "oh -0400 America East". Having
> any info at all for %Z would allow me to easily replace that already
> buggy mapping that exists in my head right now with something that's
> at least a bit more accurate, e.g. I remember that +0900 is Japan, but
> I can't now offhand recall what timezones India is at.

I can't either. But nor could I tell you which timezone abbreviations they use. ;)

>     Author: Jeff King <peff@peff.net>
>     Date:   Fri May 19 08:59:34 2017 -0400 (New York, Havana, Santiago etc.)

But I don't live in any of those places. :)

I see your point, though. I wouldn't want that on, but I wouldn't have an objection to turning that into a configurable feature. But I'm not sure we would just want it plumbed through to %Z. It seems like you'd potentially want it on for any dates that show the numeric zone.

The biggest headache would be managing the reverse-mapping to cities. It would be nice if there were some way to access the system zone database, but I doubt there's a portable way to do so. And besides, it would probably come up with way too many options (e.g., even just in the US -0500 encompasses not just what we normally think of as Eastern Time, but lots of little localities who do or do not handle DST; we obviously wouldn't want to mention them, but I don't know how we'd limit the tz database entries to only "you know, the important ones").

-Peff