Calender

[TRScheel]

This must be the way that kid from a few years back used. The one who was all the rage for being able to figure out the day of the week for any day past or future in his head.

I always knew that kid had a secret...

[Darryl]

I think the leap year check is that the leap year is divisible by 4 and not by 400.

1600 and 2000 were not leap years.

If your calendar doesn't need to go out that far, the 400 check isn't worth it.

1600 and 2000 Were leap years.

The rule is:divisible by 4 is a leap year unless divisible 100, then not leap year unless also divisible by 400, then it is.

[TRScheel]

1600 and 2000 Were leap years.

The rule is:divisible by 4 is a leap year unless divisible 100, then not leap year unless also divisible by 400, then it is.

<cry>Oh god, the rules just keep piling on... </cry>

[ravenspoint]

<cry>Oh god, the rules just keep piling on... </cry>

As I said in my first post:

"Date calculations are notoriously difficult, with many frustrating special cases that will catch you if you do not test your code to death with every possible date.

Do not undertake this lightly!"

[TRScheel]

NOTE TO SELF:

Let someone else deal with dates, focus on just getting one

=P

[JosAH]

What is that!! I have seen you pull all sorts of rabbits like this out of your hat.

Where did you learn all of this stuff? :)

Zeller's congruence rule and the [4, !100, 400] leap year rule is all you need to
produce a calendar for any month of any year you like. There's nothing complicated
about it.

Zeller's congruence rule calculates the Julian day number for a date; the difference
between the Julian day number for two dates is the difference in days for those
two days. The Julian day number mod 7 gives you the day of the week for that
date.

Of course all assuming a Gregorian calendar of course.

kind regards,

Jos (old bag of old tricks ;-)

[JosAH]

Date calculations are notoriously difficult,

That simply is not true; see my previous replies.

kind regards,

Jos

[ravenspoint]

That simply is not true; see my previous replies.

kind regards,

Jos

Really? Ever hear of a little thing called Y2K?

Perhaps 25% of my contract revenue comes from writing calendar code. I usually get this work after someone has given up in frustration. They start out optimistically, with a happy-go-lucky spirit akin to yours, perhaps, and are flummoxed by the ever mounting special cases. Or they hire it out cheap, to someone who has never coded a serious date class before and so who bids way less than I do - but I get the job the second time around :-)

[TRScheel]

This brings this to mind (to be more kosher, I moved the joke to the jokes thread, look for my last post):

Y2K Joke

.... On topic, after reading through this thread, I am curious as to what special cases would not work with that formula?

[JosAH]

Really? Ever hear of a little thing called Y2K?

That was a hype and a lot of crappy software. Zeller's congruence rule, the
[4, !100, 400] leap year rule and enough resolution for the time stamps
(8 bytes mayhap?) take care of the rest. Not much to be proud of to get it right.
To get it wrong takes quite a bit of stupidity though and having to fix it is very
boring IMHO. I don't do that type of 'work' thank you.

kind regards,

Jos

[ravenspoint]

You want special cases?

here's one:

When is Easter Bank Holiday in the year X in country Y?

Well, Easter Sunday is the first sunday after the first full moon after the vernal equinox which is the first day of spring when the sun stands at the zenith on the equator at noon. The Bank holiday is either the Friday before, or the Monday after, depending on the country.

Now any calendar coder worth his salt can deal with that. If that seems easy, try the day the Japanese banks close to celebrate the emperor's birthday?

[ravenspoint]

That was a hype and a lot of crappy software. Zeller's congruence rule, the
[4, !100, 400] leap year rule and enough resolution for the time stamps
(8 bytes mayhap?) take care of the rest. Not much to be proud of to get it right.
To get it wrong takes quite a bit of stupidity though and having to fix it is very
boring IMHO. I don't do that type of 'work' thank you.

kind regards,

Jos

IMHO, your post is downright rude. 'Kind regards', indeed.

The OP wanted to know if it was reasonable to undertake a calendar coding task. I believe I gave him fair warning. If he is still reading this long thread, then I expect my warning will have been reinforced - plus the knowledge that even if he succeeds he won't get any respect from the likes of JosAH

[JosAH]

You want special cases?

Nope not me thank you; I feed them to my rule based 'database' (mind the
quotes). Rule based programming is quite an old and well known little discipline;
I use it for those silly irregularities all the time. Astronomic (Solar) rules are just
calculus and I can't consider them 'special cases' either.

kind regards,

Jos

[archonmagnus]

Technically, the OP just wanted a calendar. Not a listing of all the holidays, festivals, celebrations, and other arbitrary (said, tongue-in-cheek) data that's printed on one. I took that to mean a standard grid of 28/29/30/31 boxes with only numbers in them correlating to the days of the week. In doing so, I've always just used the abridged code below to determine the first day of the month, and then another bit of code to space the numbers correctly in my calendar programs:

[code=cpp]
int dayOfWeek(int month, int day, int year)
{
// This function determines what day of the week a specific date falls on

int DOW;

if (month < 3)
{
month += 12;
year -= 1;
}

DOW = (day + (2 * month) + (int)((float)(6 * (month + 1)) / 10.0)
+ year + (int)((float)ye ar / 4.0) - (int)((float)ye ar / 100.0)
+ (int)((float)ye ar / 400.0) + 1) % 7;

return DOW; // 0 = Sunday
// 1 = Monday
// 2 = Tuesday
// 3 = Wednesday
// 4 = Thursday
// 5 = Friday
// 6 = Saturday
}
[/code]

[ravenspoint]

Well, archonmagnus, if that is all you want from your calendar, you can let the C runtime library do the work for you. As I explained in my first post to this thread, the best place to start a calendar project is with struct tm.

This does all you need:
[CODE=c]
#include "stdafx.h"
#include <time.h>

int dayOfWeek(int month, int day, int year)
{
// This function determines what day of the week a specific date falls on
struct tm Time;
memset( &Time, '\0', sizeof( Time ) );
// the tm structure codes years counting from 1900
Time.tm_year = year - 1900;
//The tm structure numbers months from 0 - 11
Time.tm_mon =month - 1;
Time.tm_mday = day;
Time.tm_hour = 12;
Time.tm_isdst = -1;
_mktime64( &Time );

return Time.tm_wday;

}

int _tmain(int argc, _TCHAR* argv[])
{
int m, d, y;
printf("Enter month day year\n");
scanf("%d %d %d",&m, &d, &y );

int DOW = dayOfWeek( m, d, y );

printf("Day of Week %d\n",DOW );
return 0;
}

[/CODE]

Enter month day year
7 19 2007
Day of Week 4

I find most of the posts to this thread very strange. I cannot believe they are intended to help the OP. They address problems that are already solved by the C runtime, struct tm and _mktime64(). They dismiss problems which the OP will likely have to face as if they were somehow beneath the dignity of the posters.

archonmagnus is the only poster who has shown some code and made a claim to have actually tackled calendar problems. The rest appear to be using this thread to demonstrate their arrogance, contempt for ordinary coders , and a total ignorance of the calendar support offered by the C runtime library.

Let me make a suggestion. If the Original Poster still wants to tackle his calendar project ( something I can barely believe he would after reading this thread ) then he may perhaps wish to send me a private message and I will endeavor to offer him useful, practical advice without having to endure sniping from the academic types who have hijacked this thread.