"singhals" <[email protected]> wrote in message news:[email protected] > Tony Proctor wrote: >> >> "singhals"<[email protected]> wrote in message >> news:[email protected] >>> [email protected] wrote: >>>> Tony Proctor wrote: >>>> >>>> ...snip a lot... >>>>> >>>>> The principle is also true of time-zones. If someone was born on >>>>> 9-June >>>>> in >>>>> the US and someone else on 9-June in UK then they aren't necessarily >>>>> the >>>>> same day and should not collate as equals. Once those dates are >>>>> compiled >>>>> into the internal format then the distinction is no longer applicable >>>>> and >>>>> the computer treats all compiled dates in the same fashion. >>>> >>>> <Scratch my head> In what way would the time zones problem be >>>> resolved >>>> because the program converts the human-readable date to an integer? >>>> That >>>> integer also has to start from a reference point, and choosing that one >>>> is >>>> as problematic as any other. It could be e.g. UTM time, but that will >>>> not >>>> resolve anything. >>>> An example: the first moonlanding is for the Americans 20th July 1969, >>>> somewhere late in the evening. But here in Europe it was already 21st >>>> July. >>>> So if you would introduce an worldwide numbering scheme for the time >>>> (based >>>> on UTM), and ask that system on what day the first moonlanding was, it >>>> would >>>> answer "monday", which in the American context is plainly wrong. >>>> Base your system on any other reference point will never avoid such >>>> problems. >>> >>> And what about the other calendars that some of us need to accommodate? >>> 1941 on the Jewish or Hindu Calendars sure isn't 1941 on the >>> Euro-American >>> calendar. >>> >>> Cheryl >> >> Sorry Cheryl, I only just noticed that the cross-posting only worked for >> half the thread. Hence, some of my replies only appeared in the >> soc.genealogy.britain group. >> >> I'm not sure if you caught the gist but basically, the way you count your >> days (i.e. your calendar), the order in which you write your dates (e.g. >> day >> before or after month etc), and the local time-zone are all >> manifestations >> of our own symbolism. Compiling them all into a common "timestamp" >> representation that's relative to a specific UTC date means that a >> computer >> doesn't have to worry about that. It can treat all such dates in the same >> way and handle them efficiently and unambiguously as "long integers". In >> other words, the external format that we read and write is only important >> during data entry and during reporting (incl. charting) - not during >> analysis, collation, etc. >> >> You may find this obvious but a lot of people find it hard to make the >> split. There's nothing fundamental about our calendar or the way we each >> write dates. As the thread points out, there are many different schemes >> out >> there. The important thing for handling disparate types of date is to get >> them on a common footing. Using an offset (in seconds, milliseconds, or >> whatever) from some fixed point, recognised around the world - i.e. a >> "timestamp" - is the way (good-)software does it. > > > I quite agree that time is fluid, relative, and artificial ... I _am_ > wondering though whether that's a problem that really /needs/ fixin'. > > > It's not something that "needs fixin" so much as needs addressing in genealogical (& historical) data. Arguing over whether to use the Gregorian or Julian calendar is a little like arguing over using miles or km for distance, and arguing over whether days come before or after months is like arguing over whether to write monetary data as 2$ or $2 (different countries again). Dates should be stored in a consistent and efficient internal format. The units and representation are only of interest when it has to be displayed to someone - presumably from planet Earth ;-) Tony Proctor