Deutsch English Français Italiano |
<vtpa38$369rc$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Richard Heathfield <rjh@cpax.org.uk> Newsgroups: comp.lang.c Subject: Re: "A diagram of C23 basic types" Date: Wed, 16 Apr 2025 23:13:58 +0100 Organization: Fix this later Lines: 66 Message-ID: <vtpa38$369rc$1@dont-email.me> References: <87y0wjaysg.fsf@gmail.com> <vt1a7f$i5jd$1@dont-email.me> <vti36r$g4nu$2@dont-email.me> <slrnvvqhmc.2eh69.candycanearter07@candydeb.host.invalid> <vtjknt$1sp26$1@dont-email.me> <vtk2f9$295ku$2@dont-email.me> <vtka7u$2ddeu$1@dont-email.me> <CNtLP.2611170$TBhc.2589292@fx16.iad> <vtm71q$78l6$3@dont-email.me> <87plhd0z76.fsf@nosuchdomain.example.com> <slrnvvvdch.3gc99.candycanearter07@candydeb.host.invalid> <87cydb28gu.fsf@nosuchdomain.example.com> <S2ULP.1346551$BrX.394554@fx12.iad> <vtp6hq$3349g$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 17 Apr 2025 00:14:00 +0200 (CEST) Injection-Info: dont-email.me; posting-host="8568a0bda857d5fab61a83465edc4873"; logging-data="3352428"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+iN6PlOxaJv72DQBFUIRwZK/1e7E0+w8W18+pyBarUDA==" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:9Rezkb/MRsXswOi5133x0ORcGks= Content-Language: en-GB In-Reply-To: <vtp6hq$3349g$1@dont-email.me> Bytes: 3906 On 16/04/2025 22:10, BGB wrote: <snip> > One shorthand is to assume a year is 365.25 days (31557600 > seconds), and then base everything else off this (initially > ignoring things like leap-years, etc, just assume that the number > of days per year is fractional). > > Then, say, 2629800 seconds per month, ... > > For some other calculations, one can assume an integer number of > days (365), just that each day is 0.07% longer. > > For date/time calculations, one could then "guess" the date, and > jitter it back/forth as needed until it was consistent with the > calendar math. > > Estimate and subtract the year, estimate and subtract the month, > then the day. Then if we have landed on the wrong day, adjust > until it fits. > > Not really sure if there was a more standard way to do this. Half a lifetime ago I found an algorithm on the Web and turned it into these two functions: long tojul(int yp,int mp,int dp) {long a=(14-mp)/12,y=yp+4800-a,m=mp+12*a-3,jdn=dp+(153*m+2)/5+365*y+y/4-y/100+y/400-32045; return jdn;} void fromjul(int *yp,int *mp,int *dp,long jdn){long y=4716,j=1401,m=2,n=12,r=4,p=1461,v=3,u=5,s=153,w=2,b=274277,c=-38,f=jdn+j+(((4*jdn+b)/146097)*3)/4+c,e=r*f+v,g=(e%p)/r,h=u*g+w;*dp=(h%s)/u+1;*mp=((h/s+m)%n)+1;*yp=e/p-y+(n+m-*mp)/n;} long jd = tojul(2025, 4, 16); /* gives 2460782 */ fromjul(&y, &m, &d, 2460782); /* gives 2025, 4, 16) */ Day of week: take the Julian date % 7, then 0 is Monday, 1 is Tuesday and so on: $ expr `./juldate 16/4/2025` % 7 2 It's not perfect, but its flaws have never affected me, so I've never had to find the time to fix them. Here are some problems: 1) No account is taken of the 11-day shift in September 1752. If you care, for 2/9/1752 and prior you should add 11 days to the Julian date before using it in calculations. 2) In the real world there was no year 0. Theoretically JD1 is 1 Jan 4713BC, but it's out by a year for year 0, and another 11 days for Sept 1752. If you draw a line after the inception of the Calendar (New Style), it's fine. If you don't, it should be easy enough to wrap. I have used these functions for over 25 years now and have always found them to be very reliable. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within