Discussion regarding gregorian calender

Hi
im not asking for help here, im just creating a discussion

its about the gregorian calender

i got bored one night and was thinking about the hype surrounding year 2000 worldwide system crash, and the predicted system crash coming in the year 10000.

so i was thinking about a calender project i had in a book years ago when i first started learning vb and decided to create my own gregorian calender class.

after a little research trying to find out when christ was born exactly i found it was not likely he was born on dec 25 and i decided well if the church cant even decide when he was born then basing a calender on that is pointless so i decided to find out what day was 01\01\00. just for all you guys who might want to know, the first day of the gregorian calender is sunday.

anyway with this information i found that instead of a class containing hundreds of lines of code i could find out what day, month, year, even time( although i didnt implement that, i used the leap year) with a couple of really simple functions. using modulus.

so why is it that something so simple was not and even today is not implemented in systems worldwide, i can even find the day 10000000000 days bc, find the month 25000000000 years 1 month 5 days using a simple function which is a couple of lines long.

i'm not sure if excel uses the same methods i came to make, but they use a number to calculate days and months etc.

what do you think?

As long as we are at it why in the world don't we all start speaking the same language? That would simplify things also. What year is it for the Chinese right now anyway :confused:

Quote:

---

Originally Posted by GBeats

after a little research trying to find out when christ was born exactly i found it was not likely he was born on dec 25 and i decided well if the church cant even decide when he was born then basing a calender on that is pointless so i decided to find out what day was 01\01\00. just for all you guys who might want to know, the first day of the gregorian calender is sunday.

---

Good work. I'm assuming, however, that your calculation functions don't take into account the fact that there is no year 0 in the Gregorian calendar? It goes from 1BC to 1AD.

it doesnt matter how the gregorian calender represents the years since what i did worked perfectly. but it does create the question, if i started from 0 year (which i think i did because i tested it going back in time on the same function) and i got correct results, whats happening there. i dont have the project here so i cant test it now.

ill check it later

You might be interested in this link:

http://en.wikipedia.org/wiki/Perpetual_calendar

Moved to the General Developer forum.

The Y2K problem wasn't really about how computers works with dates but rather how people stored the date in a database. Many old time database systems didn't have a date field so you stored it in text format using only 2 digits for the year.

Operating systems stores the data as numerical values, on Unix/Linux the date is calculated by given the number of seconds that has passed since January 1st 1970, if you need a date prior to that you get a negative number.

On Windows the date is generally stored as a floating point number, where the integer part is the number of days since a specific epoch date and the decimal part is the time. So if the decimal part is 0.25 it means I quarter of the day has passed so the time is 6AM.

So there will not be a Y10K problem 8000 years from now, the problem will occur when you get an overflow of the underlying data type used to store the date information. For example if you store the date in a signed 32-bit integer on a Unix based system you will get an overflow error after 1/19/2038 (or 19/1/2038 depending on how you write your date) at 3:14:07 AM GMT. However if it's stored in a signed 64-bit integer the overflow will occur several million years after our sun has gone into a super nova and swallowed earth with it so it wont be a problem.

The same is true about the 64-bit floating point value used by Windows (it will not overflow until the end of time, where I see end of time as beyond the life expectancy of our planet).

Quote:

---

i found it was not likely he was born on dec 25

---

At a quick estimate I'd say the probabilty is 1/365, just as it is for the Orthodox 'Christmas' of January 6th, but the real problem is deciding on the year! The most common estimate is 4BC (which puts an interesting slant on the theology of Christ's pre-existence in itself) to 4AD but frankly it's no more than a guess (even leaving aside the argument about whether he was actually born at all!) You might just as well base a calendar on time immemorial (which ceased on 6 July 1189!) or the first verified recorded instance of Halley's Comet (240BC).

I think we can drop the whole discussion about the birth of Christ since this thread is not really about that.

Most of us use the gregorian calendar, and if you want to discuss if that is right or wrong regarding the birth of Christ or not then move that discussion somewhere else.

This thread is about how to best store a date from some point of time according to a calendar we already use. It's not a biblical story and it doesn't matter that the OP starting to count from year 0 and the calendar itself started from year 1. The question here is really if there is a better data type in which we can store our date in than the ones already in use. (At least that is what I got from this conversation and that is the reason this thread is not in the chit-chat forum).

Just recently someone posted about the system time being in ticks which was new to me. I knew about some software picking a point in time to "start the clock". For example, but not acurate 01/01/1970.

Here is a write up.

http://en.wikipedia.org/wiki/System_time

"Many old time database systems didn't have a date field so you stored it in text format using only 2 digits for the year". Probably true, I take my hat off to your background and knowlege. But in the IBM mainframe world is was commonly stored as a Julian date in a Comp-3 datatype (packed). That saved quite a bit of storage for those days. Especially considering you could only load 512k pages at a time. So with DDDYY was 00100 01/01/1900 or 01/01/2000? That was the issue.

From my career standpoint the mainframe job market died right after the Y2K change. Lots of jobs went to Brazil and India. It was much cheaper for small companies to get off of mainframes and mid sized computers. I still see some jobs advertised but I've been out of that game for over ten years now.

Quote:

---

Originally Posted by TysonLPrice

As long as we are at it why in the world don't we all start speaking the same language?

---

What about spelling too! Get rid of either British or American English. :rolleyes:

Quote:

---

Originally Posted by TysonLPrice

Just recently someone posted about the system time being in ticks which was new to me.

---

The system time is not really stored in ticks at all. The ticks are really just the lowest measurable time that the system clock can work at. Obviously older computer systems did not have as exact hardware timers that we have today.

Quote:

---

Originally Posted by Joacim Andersson

The system time is not really stored in ticks at all. The ticks are really just the lowest measurable time that the system clock can work at. Obviously older computer systems did not have as exact hardware timers that we have today.

---

Then I'm confused about what I read (below from the link I posted)...or maybe it is just an accumulation of ticks versus storing a tick.

System time is measured by a system clock, which is typically implemented as a simple count of the number of ticks that have transpired since some arbitrary starting date, called the epoch. For example, Unix and POSIX-compliant systems encode system time ("Unix time") as the number of seconds elapsed since the start of the Unix epoch at 1 January 1970 00:00:00 UT, with exceptions for leap seconds. Systems that implement the 32-bit and 64-bit versions of the Windows API, such as Windows 9x and Windows NT, provide the system time as both SYSTEMTIME, represented as a year/month/day/hour/minute/second/milliseconds value, and FILETIME, represented as a count of the number of 100-nanosecond ticks since 1 January 1601 00:00:00 UT as reckoned in the proleptic Gregorian calendar.

Yes, but as you can see those are two different implementation of how software can read the value of the system time, not how the actual system clock works.

Quote:

---

However if it's stored in a signed 64-bit integer the overflow will occur several million years after our sun has gone into a super nova and swallowed earth with it so it wont be a problem.

---

Now, now, Joacim. That's exactly the sort of short term thinking that led to Y2K bugs in the first place:p

Quote:

---

This thread is about how to best store a date from some point of time according to a calendar we already use

---

Actually I read it to be about how you calculate the various facets of a date (e.g. the day of the week or gregorian equivalent to Julian) from a given datetime value rather than how to store it. If that is the case then I think this generally is calculated as the OP is describing. When you ask for the day of the week for 01/01/01 the fact that it's a Sunday (don't know if it is or not, just pulling an example from the sky) isn't stored anywhere, it's calculated on the fly using exactly the sort of algorithms the OP is suggesting.

My understanding was that there were actually a few issues surrounding Y2K but they all boiled down to how the year part of a date was represented , which is not quite the same as saying how it was stored. Although how you choose to store a date is a form of representation so dates stored with a 2 digit year were certainly part of the problem. But even on systems where the date was stored in strings with a 4 digit date the code needed checking in case the code running over it ever represented and/or manipulated the date in a 2 digit format. I'm being pedantic, I know, but pedantry's my natural state.

I think the size of the datatype used to hold a numeric representation of a date is another issue again. I'm not sure anyone is mixing the two up in the this thread but thought it was worth explicitely separating the two for clarity. Any data type overflow problems we're going to experience will come at some arbitrary point in time as Joacim indicated in post 6 rather than conicided with an obvious milestone in a "human" calander as Y2K did.

I worked as a consultant during the Y2K era - somehow got people to think I knew COBOL... Helped a company that was going to SAC but would not be ready by 2000 and had lots of IF conditions in code that needed to be changed. They used the formula of yy<20 is 20yy else 19yy. They had outsourced to a company in Ireland I think (that was taking too long) - but I saved them like $100,000 doing it all by myself - wrote a code-update program that read in the cobol source and auto-edited those lines where dates were found - then you just had to eyeball the rest of the code to make sure it didn't miss anything. That kept me busy for 6 months :) Good income $$