[tz] Ethiopia local time
tim at timtimeonline.com
Wed Sep 12 21:00:43 UTC 2018
Formally speaking, Ethiopia is already "supported" by tz insofar as its
offset of UTC+3 is recorded and referenced as Africa/Addis_Ababa (which is
a link to Africa/Nairobi). But, even if we ignore the differences between
atomic and solar time — it sounds like both see some use, depending on the
precision required — the unique way of naming the hours is a different
Much like we're seeing with current discussion re: fallback transitions in
mid-20th-century Japan, the tz database isn't really concerned so much with
what the hours are *called* as how they are *counted*… Or at least, that's
the best I can say in words; it's a wiggly distinction, to be sure, and
edge cases like this do exist. All tz does, though, given a timestamp, is
to convert that into some local reckoning by spitting out the elements of a
Gregorian date and a time-of-day according to a standard 24-hour clock,
counting from 00:00:00. Obviously, that intuition gets hairy at various
time discontinuities (DST and leap seconds are both examples, but are not
handled analogously). However, convention has been established by some
decades of global precedent and practice. While it would be technically
possible to implement different models for this, it would likely require
some major code changes.
In most of the world, tz's output maps pretty cleanly to how time is
reckoned by everyday folk: e.g., right now, we're I'm at, it's 17:00. In
some parts, there may be a conventional mapping to other customary
terminology; e.g., it's 5:00pm. This 12-hour system maps what tz calls
"hour 0" to the concept of "12am", and so on through "hour 23" being called
"11pm". And while it is widely supported in most systems because it is a
relatively simple transformation and its use is prevalent throughout the
world (though a historical dose of US-centrism likely helped, too), it has
nothing to do with tz's outputs themselves, and more to do with how those
results are formatted. In many parts of Europe and Asia, 17:00 could be
used directly and would be well-understood.
This is analogous to mapping dates to different calendar systems: tz uses
the proleptic Gregorian calendar and will tell me, in its structured data
format, that today is 2018-09-12, and while that's directly useful to
telling me it's "12 September 2018" in the calendar I use, if I wanted to
know that it was "3 Tishrei 5779" in the Hebrew calendar or "1 Muharram
1440" in the Islamic calendar, I would need to perform a calculation, and
that calculation is outside the scope of tz.
The gut reaction of some might be to paper over Ethiopia's unique system by
picking some timezone 6 hours east or west (UTC–3 or UTC+9, for example),
but it raises additional questions: When should the date change over, near
dusk, near dawn — or still at "midnight", which is to say "6 o'clock"?
Does traditional Ethiopian timekeeping have the same notion of "am" or
"pm", and is that even accurate terminology, if we were to translate that
notion into English? Does Ethiopian practice match the Western convention
which starts the "am" and "pm" periods with the hour called "12" and not
I'd be inclined to say that the "correct" way to support the traditional
Ethiopian timescale would be for tz to still output Ethiopian time in the
standardized way it already does, and for applications and operating
systems to then understand that "17:00" in the standard system doesn't mean
"5 o'clock", but rather should be displayed to be understood as "11
o'clock". It could be another localization option, just like alternate
calendars are today. Unfortunately, unlike the various calendar systems,
which enjoy a decent amount of support, Ethiopia is (to our knowledge)
unique in this regard. But a decent thought experiment would be to
consider how tz and localization projects like CLDR would have managed
Time <https://en.wikipedia.org/wiki/Decimal_time> in the French
Revolution. That's a *very* different way of counting hours; at least
Ethiopia's is relatively similar to things we already support.
Depending on how seriously others take, say, the prospect of supporting
other timescales entirely (TAI or GPS, perhaps, but maybe as far-reaching
as Mars time) becoming important in the future, the place for that sort of
support might land in that project, be it tz or otherwise. But for now, I
think it's more of a localization issue than a timekeeping one: They're
using different names for the same underlying thing.
On Wed, 12 Sep 2018 at 16:06, <Paul.Koning at dell.com> wrote:
> > On Sep 12, 2018, at 3:58 PM, Steve Allen <sla at ucolick.org> wrote:
> > On Tue 2018-09-11T22:23:01-0700 Paul Eggert hath writ:
> >> I'm afraid not, as it's based on solar time.
> > The article gives the impression that it's not really solar because an
> > hour of imprecision is culturally irrelevant, so it's really just 6
> > hours different from what a cell phone says. But even with that
> > simplicity I don't think that tz should implement something without a
> > much more authoritative and clear source for when the Ethiopian day
> > begins.
> > --
> > Steve Allen <sla at ucolick.org> WGS-84
> > UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat
> > 1156 High Street Voice: +1 831 459 3046 Lng
> > Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
> That brings up an interesting question.
> What does the TZ database mean "local time" to be? Time in its common
> representation where zero is midnight and 12 o'clock is noon? Or is it
> meant to account also for local conventions that zero is some point in the
> day different from midnight?
> If the former, then this issue is out of scope. If the latter, then it
> suggests there might be two Ethiopia zones, one for "midnight origin" (the
> one we have now) and one for "local convention" which combines the offsets
> from latitude, and the offset from the different convention of what the
> starting point is.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz