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