On Wed, Dec 04, 2013 at 05:53:02PM -0600, Dave Rolsky wrote: > On Thu, 5 Dec 2013, Alfie John wrote: > > >On Thu, Dec 5, 2013, at 09:40 AM, Zefram wrote: > >>Alfie John wrote: > >>>I guess it's a tautology seeing as that's what's defined in the etcetera > >>>file, but was I wrong in assuming that UTC+11 meant Etc/GMT+11? > >> > >>Yes. Etc/GMT+11 is UT-11h, and Etc/GMT-11 is UT+11h. You can also see > >>this by looking in the Olson etcetera file: > >> > >># Zone NAME GMTOFF RULES FORMAT [UNTIL] > >>Zone Etc/GMT-11 11 - GMT-11 > >>Zone Etc/GMT+11 -11 - GMT+11 > >> > >>Such zic input, specifically the GMTOFF column, uses the usual sign > >>convention; you can see here that the zone names use the opposite > >>convention. > > > >Cool, thanks for the clarification. > > > >I'd hate to think of how much software out there assumes the same as I > >did. > > Does any sane software actually use these ancient time zone names? > > The only useful thing to do is use a zone like America/Chicago so > you get DST transitions and such. If you want a DST-less zone that's > simple to understand, you should use UTC, not some fixed offset from > UTC (which will very confusingsly match up with different local time > zones as DST comes and goes in various places).
This is a point of confusion to me. I manage several research data loggers, pretty much all in our local area, and the convention has long been to keep them on local 'standard' time, no DST, just a fixed offset from UTC. I did end up using the ..::OffsetOnly module on a recent server job, but it seems fairly awkward (but works great!) compared to having the kind of fixed-offset zones available as described in this thread. I do agree for the most part that using UTC on the loggers would be simpler to manage, and would definitely go that way if we had deployments in other zones, but for now need to support legacy systems using the local non-DST zone. I guess that, to me, the ideal solution would be to have zones like the 'Etc/' ones, but hopefuly using the less funky modern offset sense, if that might be somehow considered for the future. I considered using the America/Anchorage zone and then applying a flag to disable DST, but that could wreak havoc if DST ended up getting un-disabled accidentaly, perhaps sitting there for months before going into effect. Having something like UTC-0900 or UTC-9 would seem like a simple and non-ambiguous solution. Another off-the-cuff thought might be to apply a suffix, e.g., America/Anchorage/noDST, which at least would be explicit in the setting and would not have to rely on another step to disable DST. Ken
