Re: Microsoft to force new Outlook on Windows 10 PCs

On Fri, 17 Jan 2025 16:00:55 -0600, Physfitfreak wrote:

 
Even if you accurately count the number of days past since, say, the day
with date 1/17/1700, it won't mean you have all the information about
that day's correct location in that year; because, Earth's tilted axis
of rotation is not along a fixed direction. The axis wobbles, or
"precesses" all the time. So a historian who wrote down the date as
1/17/1700 on that day, will slightly be in a different time of the year
compared to the present day's 1/17/2025.
 
As long as the difference falls below one day, this is not that
important. But if you go back farther in time to Darius's era, this
difference places you in a different season of the year. A historian who
according to your calculations would've written down the date 1/17/-1500
in his notes, was not on the January 17th of that year! He was in
another season of that year. Therefore your calculated result of
1/17/-1500 is meaningless.
 
This may look a rather simple astronomy problem, but when you want to
program it, it gets tough sometimes. And there are options to take to
correct the discrepancies. I took the option of modifying the length of
a day just enough to take care of precession of the axis of rotation of
Earth, as well as of course its orbiting around the sun (which by itself
introduces one day of discrepancy per year.)
>

I understand what you are saying, but, unfortunately, I am not well
versed in astronomical calculations and thus I cannot competently
respond to your comments.

However, I do suspect that the problem of accurately rectifying Julian
dates to various solar/lunar calendars has been solved long ago.

We need input from the GNU/Linux "experts" on this NG but I believe
that the "experts" are only a bunch of fat-chewing ignoramuses that
cannot distinguish their asses from a hole in the ground.



--
Systemd: solving all the problems that you never knew you had.