"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. Tony Proctor

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'.