LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What's with 12AM Friday January 01, 1904?

For those of you who don't know, LabVIEW keeps track of time elapsed since 12AM January 01, 1905 in order to calculate the current date and time in seconds.  I can understand the January 1st part, and the 12AM part, since is marks the beginning of a new year, but why 1904?  Why not 1905, or 1923?  Or better yet, going with the whole beginning of a new year, why not make it the beginning of a new century also, and pick 12AM, January 01, 1900?  Has anybody ever heard of a good reason for picking this day and time to start counting seconds?

~Jo-Jo
Message 1 of 16
(15,214 Views)

I've always kinda wondered that too.  Here's an article on microsoft.com that discusses the 1900 date system vs. the 1904 date system on computers.  Apparently it's not just LabVIEW that deals with the 1/1/1904 date.

-D

Message 2 of 16
(15,205 Views)

Nice article, Darren- I think this line is particularly important for the LabVIEW case:

"Because of the design of early Macintosh computers, dates before January 1, 1904 were not supported..."

Since early versions of LabVIEW were designed on early Macintosh computers I'm guessing that the 1904 date is just a holdover from that era.  I know there used to be a similar Mac-related holdover in the LabVIEW binary file i/o VIs- LabVIEW used to write binary files using Big Endian representation (unlike most Windows apps which use Little Endian).

 

Tom W
National Instruments
Message 3 of 16
(15,189 Views)
Thanks for the link...

Interesting.

~Jo-Jo
0 Kudos
Message 4 of 16
(15,181 Views)

Here's the deal with January 1, 1904. Most (all?) operating systems store time as the number of seconds ( or microseconds, etc.) since a certain time. This time is call the epoch. The number of seconds that the Mac could store covered about 130 years. The programmers wanted the system to be able to cover the birthdays of most users, so the epoch needed to start in the early 20th century. So why not start at January 1, 1900?

The Macintosh designers needed to squish a lot of code into a very small amount of ROM/RAM. They were looking for any kind of tweak that could save them some room. The code to turn the number of seconds since the epoch into a date (like March 29, 1973) needs to know how many days there are in a year. Which means you need code to determine if a year is a leap year.

A year is a leap year if it is a multiple of 4 unless it is a multiple of 100 except if it is also a multiple of 400. So, 1900 wasn't a leap year (multiple of 100), but 2000 was (multiple of 100, but also a multiple of 400). By avoiding the year 1900, the Mac designers never had to worry about the 100/400 part of the leap year rule (because the 130 year span would only cover 2000 which was a leap year). If the year was a multiple of 4, it was a leap year.

So why not 1901 or 1902 or 1903? By starting with a leap year they didn't need an 'offset', just another way to save a little bit of space.

And since LabVIEW started on the Mac, it inherited some of those quirks.

Today the Mac doesn't use the 1904 epoch, but LabVIEW still does. NI needs a cross-platform epoch and a standard doesn't exist so January 1, 1904 is as good as any.

Pat

Message 5 of 16
(15,121 Views)
Interesting Fact: The Microsoft link above talks about the 1900/1904 difference. Excel uses January 1, 1900 as its internal epoch. How did Microsoft deal with 1900 not being a leap year? They didn't! February 29, 1900 is a valid date in Excel even though that date never happened.
 
Now, as a Mac fan I would love to point a finger at Microsoft and laugh about this, but it turns out they did this for a reason. Why?! When Excel first came out it was competing against Lotus 1-2-3. Microsoft wanted it to be easy for Lotus users to switch to Excel and bring their spreadsheets with them. Lotus 1-2-3 has the 1900 bug so Microsoft decided to copy the behavior. Here is a link that talks about it http://support.microsoft.com/default.aspx?scid=kb;en-us;214326.

Message Edited by Lavezza on 08-29-2006 03:22 PM

Message 6 of 16
(15,118 Views)
And here's a story from a great blog illustrating this even better.

___________________
Try to take over the world!
Message 7 of 16
(15,093 Views)
Great story Lavezza, very interesting !
Smiley Happy

We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

0 Kudos
Message 8 of 16
(15,088 Views)
So, it sounds like we will have a Y3K bug...Smiley Happy
0 Kudos
Message 9 of 16
(15,053 Views)
Earlier than that.  The 32-bit date will overflow sometime around 2040. Then we can party like its 1904! Robot Very Happy
Message 10 of 16
(15,037 Views)