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. -- Best regards, Nickolay Olshevsky
On Tue, Apr 15, 2014 at 09:23:59AM +0300, Nickolay Olshevsky <o.nickolay@gmail.com> wrote:
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. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_,_/ /_/\_\
On Thu, Apr 17, 2014, at 6:47, Marc Lehmann wrote:
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.
On 17/04/2014 13:29, random832@fastmail.us wrote:
On Thu, Apr 17, 2014, at 6:47, Marc Lehmann wrote:
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). -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
On Thu, Apr 17, 2014, at 9:20, Ian Abbott wrote:
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.
Date: Thu, 17 Apr 2014 13:04:57 -0400 From: random832@fastmail.us Message-ID: <1397754297.16395.107638265.57E3EC20@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
On Thu, Apr 17, 2014, at 14:57, Robert Elz wrote:
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.
On 17/04/14 18:04, random832@fastmail.us wrote:
On Thu, Apr 17, 2014, at 9:20, Ian Abbott wrote:
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 :( -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
On Thu, Apr 17, 2014 at 08:29:52AM -0400, random832@fastmail.us wrote:
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. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_,_/ /_/\_\
On Thu, Apr 17, 2014, at 9:39, Marc Lehmann wrote:
On Thu, Apr 17, 2014 at 08:29:52AM -0400, random832@fastmail.us wrote:
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.
On 2014-04-17 11:02, random832@fastmail.us wrote:
On Thu, Apr 17, 2014, at 9:39, Marc Lehmann wrote:
On Thu, Apr 17, 2014 at 08:29:52AM -0400, random832@fastmail.us wrote:
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. -- Take care. Thanks, Brian Inglis
On 18/04/14 23:55, Brian Inglis wrote:
On 2014-04-17 11:02, random832@fastmail.us wrote:
On Thu, Apr 17, 2014, at 9:39, Marc Lehmann wrote:
On Thu, Apr 17, 2014 at 08:29:52AM -0400, random832@fastmail.us wrote:
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! -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
On Fri, Apr 18, 2014, at 18:55, Brian Inglis wrote:
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.
On Sat, Apr 19, 2014 at 10:43 AM, <random832@fastmail.us> wrote:
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
On 2014-04-19 09:00, Gwillim Law wrote:
On Sat, Apr 19, 2014 at 10:43 AM, <random832@fastmail.us <mailto:random832@fastmail.us>> wrote:
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! -- Take care. Thanks, Brian Inglis
Date: Sat, 19 Apr 2014 10:43:15 -0400 From: random832@fastmail.us Message-ID: <1397918595.3173.108174785.100A5BCD@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
participants (8)
-
Brian Inglis -
Gwillim Law -
Ian Abbott -
Lester Caine -
Marc Lehmann -
Nickolay Olshevsky -
random832＠fastmail.us -
Robert Elz