[tz] Time zones in Ukraine

[Nickolay Olshevsky]

Hi.
I am aware about tz database for a while, and today, during FreeBSD
installation found out that it still propose ancient and non-usable
zones like Ruthenia, Zaporozhye or Crimea for time zone in Ukraine,
while for last years only one time zone exists at the whole Ukraine area
(except Crimea for now).
So, it would be nice to remove all of them except Ukraine/Kyiv, or is
this not possible due to historical reasons (to keep history of all
those time zones)?
Also, the other issue is that in Ukrainian language correct spelling is
Kyiv, not Kiev (russian pronunciation).
It would be quite logical to change default zone to Europe/Kyiv.
Thanks.

[Tim Parenti]

Nickolay,

The zones you mention are retained for historical reasons; in particular,
their timestamps differ in 1991 and years prior. See
https://github.com/eggert/tz/blob/6eeb85f72939e58c34bf0140fe82993270964873/europe#L2833

Additionally, tzdb uses the "mainstream English spelling" for place names
wherever possible; "Kiev" is more common in English than "Kyiv". See
https://github.com/eggert/tz/blob/cbea42a15974c395cf45dcf9bcee775c8833051b/Theory#L433

--
Tim Parenti

Post by Nickolay Olshevsky
Hi.
I am aware about tz database for a while, and today, during FreeBSD
installation found out that it still propose ancient and non-usable zones
like Ruthenia, Zaporozhye or Crimea for time zone in Ukraine, while for
last years only one time zone exists at the whole Ukraine area (except
Crimea for now).
So, it would be nice to remove all of them except Ukraine/Kyiv, or is this
not possible due to historical reasons (to keep history of all those time
zones)?
Also, the other issue is that in Ukrainian language correct spelling is
Kyiv, not Kiev (russian pronunciation).
It would be quite logical to change default zone to Europe/Kyiv.
Thanks.
--
Best regards,
Nickolay Olshevsky

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20140414/0dfa3a27/attachment.html>

[random832]

Post by Nickolay Olshevsky
Hi.
I am aware about tz database for a while, and today, during FreeBSD
installation found out that it still propose ancient and non-usable
zones like Ruthenia, Zaporozhye or Crimea for time zone in Ukraine,
while for last years only one time zone exists at the whole Ukraine area
(except Crimea for now).

Ruthenia used a different timezone in 1990 and 1991. You may have files
from 1990 or 1991, therefore you need to select that time zone to
accurately display the time of day those files were created/modified.

It sounds silly, but it's the design philosophy of the tz database. It's
not like this doesn't happen in America. I'm from Indiana - look at how
many timezones it has, instead of just using Chicago and New York. There
are eight designated cities in indiana, plus areas where you are meant
to use Chicago, Louisville, and New York.

The US has 29 zones overall, when it "should" have only eight.

[Nickolay Olshevsky]

Thank you guys for prompt answer, now I got it.
Will at least go and read what was that Rutenia :)

The another idea would be to keep somewhere list of active timezones
along with tz database, but I understand that it would be almost
impossible to add corresponding APIs everywhere.

[Marc Lehmann]

Post by Nickolay Olshevsky
The another idea would be to keep somewhere list of active timezones
along with tz database, but I understand that it would be almost
impossible to add corresponding APIs everywhere.

The problem is that these extra timezones are "active" timezones, and for
systems (or timestamps) that did follow the ruthenia rules in the past (as
an example), it is the correct timezone right now, and not the kiev one.

Imagine you created a file on such a system in 1989, using those
rules. Then the local time you created it in is the ruthenia one - the
kiev rules would likely give you the wrong time.

While files that old are rare, and one could argue that the kiev rules are
more commonly used, that doesn't mean the other rulesets are not valid
anymore.

[random832]

Post by Marc Lehmann
Imagine you created a file on such a system in 1989, using those
rules. Then the local time you created it in is the ruthenia one - the
kiev rules would likely give you the wrong time.

And yet we don't care to store what timezone the file was created in,
whereas the system might have been somewhere else in 1989 and moved to
Ruthenia now.

[Ian Abbott]

Post by random832

Post by Marc Lehmann
Imagine you created a file on such a system in 1989, using those
rules. Then the local time you created it in is the ruthenia one - the
kiev rules would likely give you the wrong time.

And yet we don't care to store what timezone the file was created in,
whereas the system might have been somewhere else in 1989 and moved to
Ruthenia now.

Unix systems store the timestamp in universal time, so the local
timezone the system was in at the time the file was
created/modified/accessed shouldn't matter (assuming the system time was
set correctly).

[random832]

Post by Ian Abbott
Unix systems store the timestamp in universal time, so the local
timezone the system was in at the time the file was
created/modified/accessed shouldn't matter (assuming the system time was
set correctly).

This entire conversation is predicated on the assumption that we want to
display it in local time. If there is a correct answer, then the
timezone the file was created in is a better candidate than the timezone
your current geographic location (where the file may not have been
created) observed. Rejecting the assumption makes the _entire_ exercise
irrelevant, not only the part I brought up.

[Lester Caine]

Post by random832

Post by Ian Abbott
Unix systems store the timestamp in universal time, so the local
timezone the system was in at the time the file was
created/modified/accessed shouldn't matter (assuming the system time was
set correctly).

This entire conversation is predicated on the assumption that we want to
display it in local time. If there is a correct answer, then the
timezone the file was created in is a better candidate than the timezone
your current geographic location (where the file may not have been
created) observed. Rejecting the assumption makes the_entire_ exercise
irrelevant, not only the part I brought up.

There is much debate in many areas on just what 'history' is important.
It was back in the 1990's that we started using UTC exclusively for
storing time data and add location as a means of identifying a local
time. Processing historic data where tz offset may be suspect is a
current problem, and the existing tz database can't be relied on to
provide valid historic material. That is why Paul has set a limit on
when the tz data is intended to be accurate from. The problem this
leaves is how to manage material that has both pre and post 'tz valid'
data. The current assumption is that everybody is using the same tz data
and I'm not sure what will happen where distributions are not providing
that with reliability? Two machines could well display different local
times for the same historic data :(

[Robert Elz]

Date: Thu, 17 Apr 2014 13:04:57 -0400
From: random832 at fastmail.us
Message-ID: <1397754297.16395.107638265.57E3EC20 at webmail.messagingengine.com>

| This entire conversation is predicated on the assumption that we want to
| display it in local time.

Probably, yes.

| If there is a correct answer, then the
| timezone the file was created in is a better candidate than the timezone
| your current geographic location

Not at all, I have lots of files I created in Australia, but when I
look at them now, it is perfectly OK to show them in my current timezone.

The files all have UTC timestamps, so that actual times for when they
were last modified, or accesses (or whatever the filesystem provides)
are accurate, so when I see the times in my current local time, I know
when they were actually modified. If I got shown some files in Australian
times (and in various US times if the file happened to have been last
touched when I was there for a while) or perhaps European timestamps, I'd
never have any idea what was up - I'd have to actually remember where I
happened to be when I last touched the file in question - and since we're
talking about files that are 15-20 years old (or more), the chances of that
are negligible.

| Rejecting the assumption makes the _entire_ exercise
| irrelevant, not only the part I brought up.

Not at all. And in any case, if you did want files displayed in whatever
happened to be the local time in the place where they were created, then
the data to make that happen would be extra information (location, or zone,
attached to every file). That's not our business. We don't do that,
nor do we advocate, nor denigrate any system that does. None of our business.

What we do do here is collect the timezone data, as accurately as we can,
so people who do have a use for it, can use it in whatever way is appropriate
to the system and applications that they have.

Whether or not you happen to have a need for some of that is irrelevant, just
as it is whether I do. Collecting all of the data, as accurately as
possible, at least starting from our current epoch, is the objective.

The epoch is currently Jan 1, 1970 (midnight, UTC) - not a surprising
choice, as originally this project was for unix (later posix) timestamps,
and as that's the epoch of those timestamps, (and = just slightly - predates
the birth of unix,) there can't logically be anything earlier.

Of course, these days, the scope of the project has expanded. it isn't
limited to just unix/posix timestamps any more, and with that, it would be
reasonable to push the epoch back earlier - personally I'd like to see that
happen, gradually. Not everyone agrees - partly simply for the pragmatic
reason that getting accurate data on what the times were used as we move
further back gets increasingly harder, and second, because the number of
timezones we would end up with would increase (were we to go back before the
introduction of standardised time - which even I don't think would be useful -
we'd need to have a different zone for everywhere on the planet, perhaps for
every house, but certainly for every town and village). Notwithstanding that,
if possible, and as the data to do it is located, I'd quite like to aim for
at least moving the epoch back to the start of the 20th century. If that
happens, lots more or what you consider "useless" zones would appear...

kre

[random832]

Post by Robert Elz
What we do do here is collect the timezone data, as accurately as we can,
so people who do have a use for it, can use it in whatever way is appropriate
to the system and applications that they have.

No part of that includes the maintenance of zone.tab at all, which is,
broadly, a recommendation of which of the zones we maintain should be
presented by default for non-technical end-users to select from. There
is no fundamental reason that recommendation should include timezones
that are redundant in the present time, solely on the basis of them
having differed 40 years ago.

[Marc Lehmann]

Post by random832
And yet we don't care to store what timezone the file was created in,

What _we_ care is pretty irrelevant, and some systems do store the
timezone, after all, if you have a posix timestamp and an archived
timezone id, you already have such a system.

What's relevant is that the correct answer to "what was the
creation/modification/change/whatever time of the file" depends on the
timezone that this is being asked for, and for that question the ruthenia
rules are as "active" as the kiev rules. Indeed, that's true for any
question of the form "what local time does this timestamp refer to".

If the question is "what local time is it right now" then indeed, ruthenia
isn't relevant (at least right now :), but that's arguably not even the
most common question being asked.

My point is that "active" with regards to this database refers to
"different after the cutoff date", and the cutoff date is not "right now"
but 1970.

In fact, a cutoff date of "right now" would probably be quite difficult to
even define.

[random832]

Post by Marc Lehmann

Post by random832
And yet we don't care to store what timezone the file was created in,

What _we_ care is pretty irrelevant, and some systems do store the
timezone, after all, if you have a posix timestamp and an archived
timezone id, you already have such a system.

My point is, if maintaining the accuracy of the local time of historical
timestamps were a common need, someone would have designed a system that
actually does this, rather than merely pretending to do it only when a
file is never moved (geographically) from its original location.

And the cost of serving this imagined need - up front rather than only
for people to go looking for it - is unbounded bloat in the timezone
selection list.

[Brian Inglis]

Post by random832

Post by Marc Lehmann

Post by random832
And yet we don't care to store what timezone the file was created in,

What _we_ care is pretty irrelevant, and some systems do store the
timezone, after all, if you have a posix timestamp and an archived
timezone id, you already have such a system.

My point is, if maintaining the accuracy of the local time of historical
timestamps were a common need, someone would have designed a system that
actually does this, rather than merely pretending to do it only when a
file is never moved (geographically) from its original location.
And the cost of serving this imagined need - up front rather than only
for people to go looking for it - is unbounded bloat in the timezone
selection list.

Not all the world's a file timestamp, to paraphrase Henry Spencer.
Real property systems have to handle dates from previous centuries.
Systems dealing with people have to be able to handle date/time stamps
from decades to more than a century in the past and the future.
Financial trading systems have to be able to handle sub-ms current times
and time frames of decades for stock holdings and long term investments.
Many of these are now built on top of the date/time handling infrastructure
provided by this project.

[Lester Caine]

Post by Brian Inglis

Post by random832

Post by Marc Lehmann

Post by random832
And yet we don't care to store what timezone the file was created in,

What _we_ care is pretty irrelevant, and some systems do store the
timezone, after all, if you have a posix timestamp and an archived
timezone id, you already have such a system.

My point is, if maintaining the accuracy of the local time of historical
timestamps were a common need, someone would have designed a system that
actually does this, rather than merely pretending to do it only when a
file is never moved (geographically) from its original location.
And the cost of serving this imagined need - up front rather than only
for people to go looking for it - is unbounded bloat in the timezone
selection list.

Not all the world's a file timestamp, to paraphrase Henry Spencer.
Real property systems have to handle dates from previous centuries.
Systems dealing with people have to be able to handle date/time stamps
from decades to more than a century in the past and the future.
Financial trading systems have to be able to handle sub-ms current times
and time frames of decades for stock holdings and long term investments.
Many of these are now built on top of the date/time handling infrastructure
provided by this project.

EXACTLY!

[random832]

Post by Brian Inglis
Not all the world's a file timestamp, to paraphrase Henry Spencer.
Real property systems have to handle dates from previous centuries.
Systems dealing with people have to be able to handle date/time stamps
from decades to more than a century in the past and the future.
Financial trading systems have to be able to handle sub-ms current times
and time frames of decades for stock holdings and long term investments.
Many of these are now built on top of the date/time handling
infrastructure
provided by this project.

A) I'm not convinced either of the applications you named need old
historical offsets either. Make a case for the property systems you
mentioned requiring measuring how many hours and minutes old something
is.

B) Zone.tab isn't relevant to those things. The only thing zone.tab is
used for is configuring the timezone of a system's clock. People who
need the historically-differing timezones _can go looking for them_,
people who don't need them shouldn't have them shoved in their faces.

[Gwillim Law]

Post by random832
A) I'm not convinced either of the applications you named need old
historical offsets either. Make a case for the property systems you
mentioned requiring measuring how many hours and minutes old something
is.
You might have to know which of two events in different countries happened

first. For example, the legacy of an estate might depend on who died first.

Gwillim Law
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20140419/6a683794/attachment.html>

[Brian Inglis]

Post by random832
A) I'm not convinced either of the applications you named need old
historical offsets either. Make a case for the property systems you
mentioned requiring measuring how many hours and minutes old something
is.
You might have to know which of two events in different countries happened first.
For example, the legacy of an estate might depend on who died first.

Or who was born first, either in the case of twins, or relatives of the same degree
born close together. I have distant sibling nieces whose first children were born
maybe a day or a few days apart, as the birth announcements were emailed some unknown
time after the events and gave no details, unlike traditional print announcements.

I have known companies who had hash generated employee id collisions, where employees
who happened to have exactly the same name and birth date were hired on the same date
in distant divisions, and there were obviously no existence or collision handling
checks, or tie breaking provisions, built into the systems.

Murphy knows there will be cases when unlikely events will occur on the same date or
at the same time. I have fixed systems where "will never happen" took from six days
to six months to occur after release: never seen a system with a "will never happen"
design decision where "never" was more than six months between release and fix dates!

[Robert Elz]

Date: Sat, 19 Apr 2014 10:43:15 -0400
From: random832 at fastmail.us
Message-ID: <1397918595.3173.108174785.100A5BCD at webmail.messagingengine.com>

| B) Zone.tab isn't relevant to those things.

Another personal observation .. I'd be quite happy to see zone.tab simply
deleted, it isn't important to the primary function of what we do, but
given that is not going to happen ...

| The only thing zone.tab is
| used for is configuring the timezone of a system's clock.

It is input data for tzselect, used on some (perhaps quite a few, but not
all) systems to let users select their timezone.

| People who
| need the historically-differing timezones _can go looking for them_,

You mean people who want to be correct, rather than simply have something
that looks OK, but is actually broken? And you're advocating that's
what we should suggest that people use - that we should go tell average
users, who don't know better, to set their timezone incorrectly?

| people who don't need them shouldn't have them shoved in their faces.

Everybody needs them. The difference isn't whether they are needed
or not, but whether or not the user knows that it is needed. And
while tzselect and zone.tab aren't exactly great on explaining to
users why they'd want Europe/Uzhgorod rather than Europe/Kiev, at
least presenting them with the option informs them hat there is
something that might not be immediately obvious going on.

If you don't think that historical data is useful, just tell the users
to set the zone to UTC+3 - which I think is correct right now. It
will make mistakes with any timestamps from a month or so ago, but
that's just historical data, and doesn't matter, right? In October
they can switch to UTC+2, and their clocks will remain correct...

kre