3 ms·
While we're nit-picking, this also doesn't account for a lot of problems which are inevitable on a 1,000 year scale, such as the lifetime of the computer's part
by ddevault 7y ago
While we're nit-picking, this also doesn't account for a lot of problems which are inevitable on a 1,000 year scale, such as the lifetime of the computer's parts, dealing with power outages, staffing for the long-term upkeep of the system, etc.
- perl4ever 7y agoThat line of code is not beautiful, it's obscene. At the very least, anything that's intended to last a long time should be written in the simplest, clearest, self-explanatory manner so as to at least give reasonable confidence it's correct. Not to mention, 952 years is a lousy approximation of a millennium. const yearSeconds = 31556926 for i = 1 to 1000 sleep yearSeconds Or, use some calendar library to get the exact number needed.
- contravariant 7y agoWhy wait for a tropical year though? Surely most people will assume it waits for a calendar year? Of course, even without leap seconds, this severely complicates the issue since you'd first need to figure out the number of leap days in the next 1000 years, which is unfortunately not fixed since 1000 is not a multiple of 400.
- perl4ever 7y agoI reconsidered the spirit of the thing, which is obviously to use C and not to use large constants or external libraries. But I still think 95% accurate is terrible, so I posted a 99.99% solution in C. Edit: I used the tropical year number without thinking about it, but (a) the difference is de minimus compared to being 5% off, and (b) I consider it undefined whether the Gregorian calendar year really is different, because who's to say we won't have an adjustment to the leap year cycle in the very long run to make them converge?