code review 5676096: time: add zoneinfo files, mainly for non-Unix systems

time: add zoneinfo files, mainly for non-Unix systems

Generated by lib/time/update.bash.

[rsc, 2012-02-19 01:36:48]

Hello bradfitz@golang.org (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go/

[rsc, 2012-02-19 01:36:57]

*** Submitted as bf726d0e6092 ***

time: add zoneinfo files, mainly for non-Unix systems

Generated by lib/time/update.bash.

R=bradfitz
CC=golang-dev
http://codereview.appspot.com/5676096

[r2, 2012-02-19 01:45:21]

can't we do this without adding 500 files to the repo?

-rob

[rsc, 2012-02-19 01:54:52]

On Sat, Feb 18, 2012 at 20:45, Rob 'Commander' Pike <r@google.com> wrote:
> can't we do this without adding 500 files to the repo?

I thought about this for a while but couldn't come up with
any that work out of the box on systems without these
files.  My favorite solution would be to just put them all
in a zip file and have package time read it, but time is a
very low-level package and can't depend on something
like zip.

I was assuming http://codereview.appspot.com/5674104
as the review for this CL - I could not get Rietveld to deal
with this CL and honestly did not expect the hg submit
to work either.

Russ

[bradfitz, 2012-02-19 02:02:08]

what's the concern?  just noise when listing all go files?

the installer(s) could unzip this in the right place, I guess, and keep a
zip in the repo, without making time depend on archive/zip

On Sat, Feb 18, 2012 at 5:45 PM, Rob 'Commander' Pike <r@google.com> wrote:

> can't we do this without adding 500 files to the repo?
>
> -rob
>
>

[r2, 2012-02-19 02:05:55]

On 19/02/2012, at 12:54 PM, Russ Cox wrote:

> On Sat, Feb 18, 2012 at 20:45, Rob 'Commander' Pike <r@google.com> wrote:
>> can't we do this without adding 500 files to the repo?
> 
> I thought about this for a while but couldn't come up with
> any that work out of the box on systems without these
> files.  My favorite solution would be to just put them all
> in a zip file and have package time read it, but time is a
> very low-level package and can't depend on something
> like zip.
> 

this adds 500 tiny files that hg must stat every time i ask it something (unless
i misunderstand how hg works), plus they're 500 files that few people will ever
need. an archive of some form seems like the answer, either one that's unpacked
if needed (not sure how that would work but i'm sure it's soluble) or maybe just
read by time. it doesn't need to be zipped, the files are small. a simple
textual archive format would do fine, like

-----Tanzania\n
data for tanzania

-rob

[r2, 2012-02-19 02:07:39]

On 19/02/2012, at 1:02 PM, Brad Fitzpatrick wrote:

> what's the concern?  just noise when listing all go files?

it's messy and wasteful and lazy and probably makes hg slower.

> the installer(s) could unzip this in the right place, I guess, and keep a zip
in the repo, without making time depend on archive/zip

that sort of approach is where i thought this idea was going, although as i said
in the other mail it doesn't need to be an outside format we would need to
depend on. hell, it could be a data definition in a go program that writes out
its elements.

-rob

[Michael Shields, 2012-02-21 19:24:48]

I don't think you want to go there.  The timezone data changes several times a
year, sometimes on short notice (days), at the whim of every national
legislature.  If this is baked into the Go language distribution, then it will
usually be slightly wrong.

[rsc, 2012-02-21 19:41:05]

On Tue, Feb 21, 2012 at 14:24,  <mshields@google.com> wrote:
> I don't think you want to go there.  The timezone data changes several
> times a year, sometimes on short notice (days), at the whim of every
> national legislature.  If this is baked into the Go language
> distribution, then it will usually be slightly wrong.

This is a fallback for systems that don't have it,
and it is only for LoadLocation.  Slightly wrong is
better than completely missing.