On Mon, 26 Feb 2018 17:18:38 -0800, Rick Johnson wrote: > On Tuesday, February 20, 2018 at 5:45:36 PM UTC-6, Steven D'Aprano > wrote: >> On Tue, 20 Feb 2018 12:42:23 -0800, Rick Johnson wrote: >> >> > For instance, if the age is queried many times a second, it would be >> > a much wiser design to set-up an event that will advance the age at >> > the end of the last second of every year >> >> Do you really mean to say that everybody in the world has their >> birthday on January 1st? We're not racehorses you know.
[...] > If you read my exact words again: > > "a much wiser design to set-up an event that will advance the age at > the end of the last second of every year" Oh, you mean the exact same words already quoted above? > ...you'll notice that i mentioned no specific date. Yes you did: "the last second of every year" is always 23:59:59 of 31st December, and it is always the same time and date "every year". Just because you didn't explicitly state the name of a month doesn't mean you didn't implicitly specify one. Perhaps you didn't *intend* to specify the last day of the year, in which case you ought to just accept that your writing wasn't as clear as you intended, instead of blaming others for failing to read your mind. > Therefore, "the last day of the year" (in relativistic terms) is > 11:59:59PM on the calendar day which _precedes_ the day of the month for > which you were born. Relativistic terms? You mean when travelling at 90% of the speed of light or in close orbit around a neutron star? There are those language skills letting you down again :-P I think you mean *relative* terms. [...] >> Under your scheme, 99.7% of records will return the wrong age (off by >> one) at least once per year. Statistically, 50% of queries will be >> wrong. > > > Can you whip-up a small code example which proves your assertion? Hey, > and feel free to include the seven dwarfs if you like. ;-) Under the racehorse scheme, 1/365 of your data will be born on the 1st of Jan, 1/365 on the 2nd Jan, and so on through 31st Dec. (Ignoring leap years.) Half of the data records will be updated early, and half will be updated late. Only those born on New Years Day (about 0.3% of the records) will be updated on the correct day. Hence 99.7% will be wrong for at least one day per year. If queries are made randomly, they'll be off by one 50% of the time. Why 50%? 1/365 of your records will never be wrong, 1/365 will be wrong one day of the year, 1/365 will be wrong two days of the year, 1/365 will be wrong three days of the year, ... 1/365 will be wrong 364 days of the year. So on average, records are wrong 182 days of the year, which is close enough to half of 365. So if you query a random record on a random day, there's close enough to a fifty percent chance it will be off by one. Now that I understand that you didn't intend this racehorse scheme, I'm not going to bother writing a simulation. But it is just simple statistics, assuming that the actual birthday is distributed randomly across the year, and assuming that queries for records come in at random times. (And to be pedantic, I mean a uniform random distribution, and that queries and birthdays are independent.) -- Steve -- https://mail.python.org/mailman/listinfo/python-list
