3 ms·

The heck? This seems silly, and like an active nuisance. Timezone data changes multiple times each year. You can see this by the tz-announce email dates [0] Wh

The heck? This seems silly, and like an active nuisance. Timezone data changes multiple times each year. You can see this by the tz-announce email dates [0] Why would I want to have to update recompile and deploy a go binary 2-10 times a year just because Morocco decided to remove DST from one of its regions? I'd much rather the go authors not encourage me to do something dumb like encode tzdata in a nonstandard un-updateable location in my binary rather than having it in a standardized location that the OS will update for me as appropriate. [0]: https://mm.icann.org/pipermail/tz-announce/ https://mm.icann.org/pipermail/tz-announce/

ithkuil 6y ago
First point: making something possible doesn't necessarily mean encouraging it (unless you meant it in the "slippery slope" sense). Second point: The way many people use containers (especially when using minimal images meant to "just run a static binary") effectively boils down to the same thing: having a "un-updateable" blob that you need to rebuild in order to get an updated version thereof. If you have an OS with a package manager, that runs without being "reimaged" for weeks, months, years, then having a process that keeps the "OS" up to date (TZ data, security updates of shared libraries, ...) is good idea. If you have a static binary in a minimal image, running in an environment where any software update entails "re-imaging" your machine (VM, container, ...), then your process already has to consider that running the same binary for months and years without any updates is very bad idea. Statically linking critical components like your crypto libraries already begs for a timely and automated rebuild process. The TZ data fits the same pattern as shared libraries. There are points to be made in favour and against shared libraries. Whatever your position is on that topic, I think it can be transferred directly to TZ embedding.
4ad 6y ago
Go will use the system timezone data, this is just a fallback the programmer must opt-in.
- 3fe9a03ccd14ca5 6y ago
  Tz data is not always available (see alpine base image, or scratch). When it is available, it may be out of date. It may never get updated in fact.

ithkuil 6y ago

First point: making something possible doesn't necessarily mean encouraging it (unless you meant it in the "slippery slope" sense). Second point: The way many people use containers (especially when using minimal images meant to "just run a static binary") effectively boils down to the same thing: having a "un-updateable" blob that you need to rebuild in order to get an updated version thereof. If you have an OS with a package manager, that runs without being "reimaged" for weeks, months, years, then having a process that keeps the "OS" up to date (TZ data, security updates of shared libraries, ...) is good idea. If you have a static binary in a minimal image, running in an environment where any software update entails "re-imaging" your machine (VM, container, ...), then your process already has to consider that running the same binary for months and years without any updates is very bad idea. Statically linking critical components like your crypto libraries already begs for a timely and automated rebuild process. The TZ data fits the same pattern as shared libraries. There are points to be made in favour and against shared libraries. Whatever your position is on that topic, I think it can be transferred directly to TZ embedding.

4ad 6y ago

Go will use the system timezone data, this is just a fallback the programmer must opt-in.

3fe9a03ccd14ca5 6y ago
Tz data is not always available (see alpine base image, or scratch). When it is available, it may be out of date. It may never get updated in fact.