Amazing

[Hickory]

Check out the sidebar of birthdays.
There sure are a lot of people that were born today, and most of them are 44 years old. WOW

The spring of 1969 must have been something.

[JRPVT]

As I recall, being in my mid teens then, it was a very cold winter with lots of snow, iirc we had one storm that dropped 48" of snow in 24 hours that year. That's a lot even for VT. So yes, the folks probably stayed warm as they could. LOL Dave BTW, Happy Birthday to all.

[Hickory]

This my be the answer.
All of you 44year olds are blizzard babies.

http://en.m.wikipedia.org/wiki/February_1969_nor'easter

[backhoe]

Naw that ain't it, Days of all us old hippies with the free love thing love and all of that!

[NavyVet1959]

More likely people do not list their real birthdays. They might use the correct month, but use the first, middle, or last date of the month. Some might further protect their info by altering the year +/- a year or two. And just putting January 1st of whatever year is common. Understandable...

[parson48]

Well, Happy Birthday to everybody!

[shooter93]

The last year of the "free loving 60's"....a lot of "celebration and rejoicing".....smiles.

[NavyVet1959]

Another thing to consider is that time=0 is 1/1/1970.

Looking at the sidebar in question, I see that most of the people are 45, thus it would mean that the system has 1/1/1970 as their birthday. That just happens to be time=0. Coincidence? I think not. Basically a database field that was initialized to zero.

[therealhitman]

+1 on both of Navy's observations.

I always put the Fourth of July!

[NavyVet1959]

+1 on both of Navy's observations.

I always put the Fourth of July!

Most UNIX / 'C" programmers know that time started at 0:00:00 GMT 1/1/1970.

[oldred]

I just got a "Happy birthday" E-Mail from the Marlin forum yesterday (1/1/15) and I didn't give that info, I just entered zeros.

[NavyVet1959]

I just got a "Happy birthday" E-Mail from the Marlin forum yesterday (1/1/15) and I didn't give that info, I just entered zeros.

Obviously the writers of the forum software did not differentiate between someone not entering something and someone who truly was born when time=0 (i.e. 1/1/1970).

With UNIX, the time value (of type time_t) is a 32-bit signed integer containing the number of seconds that have elapsed since 0:00:00 1/1/1970. At the time, it seemed like a good enough implementation for time. Because it was signed, it gave us 68 years before and after that 0:00:00 1/1/1970 in which to represent datetime values. Well, remember the Y2K stuff? That same thing is going to happen in 2038 (at 03:14:07 1/19/2038 to be precise) when adding 1 to the time value rolls over. Hopefully, they will switch to a 64-bit value for time_t by that point, but there still might be a bunch of legacy code and databases that will need to be changed to support the 64-bit field size.

For this forum's software, the writer should have had two fields -- a boolean value of whether the birthdate has been entered and a date field that was the actual birthdate. Since no one actually enters the time of their birth on things like this, using a time_t value for this is a bit wasteful. A more practical storage scheme would have been to just stored it as the number of DAYS before / after some base date. That would give you a window of 5.8M years on each side of the base date while still allowing for easy calculations.

[geargnasher]

Obviously the writers of the forum software did not differentiate between someone not entering something and someone who truly was born when time=0 (i.e. 1/1/1970).

With UNIX, the time value (of type time_t) is a 32-bit signed integer containing the number of seconds that have elapsed since 0:00:00 1/1/1970. At the time, it seemed like a good enough implementation for time. Because it was signed, it gave us 68 years before and after that 0:00:00 1/1/1970 in which to represent datetime values. Well, remember the Y2K stuff? That same thing is going to happen in 2038 (at 03:14:07 1/19/2038 to be precise) when adding 1 to the time value rolls over. Hopefully, they will switch to a 64-bit value for time_t by that point, but there still might be a bunch of legacy code and databases that will need to be changed to support the 64-bit field size.

For this forum's software, the writer should have had two fields -- a boolean value of whether the birthdate has been entered and a date field that was the actual birthdate. Since no one actually enters the time of their birth on things like this, using a time_t value for this is a bit wasteful. A more practical storage scheme would have been to just stored it as the number of DAYS before / after some base date. That would give you a window of 5.8M years on each side of the base date while still allowing for easy calculations.

Won't work. Time values still have to be in seconds in order to mark post times.

Gear

[NavyVet1959]

Won't work. Time values still have to be in seconds in order to mark post times.


I'm just talking about the birthdate field in the user database. Since the hours, minutes, and seconds are never entered, then it doesn't make sense to use that field as "number of seconds since 0:00:00 1/1/1970". Just make it the number of days and multiply by 86,400 whenever you need to compare it with a regular time_t value.

[popper]

Yea, got the marlin B.D. notice too. Mother-in-law actualy had 1/1/18 birthday (close to SmackOver). She was a 'premie' so got stuck in a shoe box and into the wood stove bread warmer for a while. Passed just before her 93rd. Wonderful gal.