"$date" in year 2000 flaw?

The command "date" states that when setting the time and date that the order is Month,Day, Hour, Minute, Year.
There is only two entries for the year "yy" . This means that unix would not be Y2K compliant.
     Can someone tell me if the "date" command has evolutionized to y2k or not. I am deeply greatful for any response. Thank you.

Who is Participating?
philiph_elvisConnect With a Mentor Commented:
Unix systems keep time internally as the number of seconds since the "epoch", which is defined as 00:00:00, Jan 1, 1970.

This number is stored as a 32 bit integer, thus it will overflow some time in 2038.

The "date" command converts from this internal representation to some other format.  By default, "date" shows the years as "YY".  This is just a display function - you could use "date +%Y" instead and see the full four digit year instead - 2000.

Thus no matter how the date command works, the internal representation of time is y2k-compliant.

The gnu version on date on my linux box takes either 2 or 4 digit years when setting the time.  It appears that if you only give it only two year numbers, the range can be between 00 and 59, however that seems to be ingored on my system - the year isn't actually changed.  you have to specify the full 4 digit year to actually change the year.  I think the two digit year is accepted and ignored for compatibility with other versions of date.

So on linux, use four digit numbers when setting the date.
While it might not seem so on casual examination, Unix does know that 00 as the year in the "date" command must be 2000. And it knows this because the epoc for Unix is something like 1972 or so. There simply weren't any Unix boxes earlier than that, therefore 00 has to be 2000, it can't possibly be 1900. Now what would happen in 3000... I think we've got enough to time to solve that one.
tionikAuthor Commented:
This is a question I know ,and I am quizing you on it.
Okay let me try one more time. The date command is Y2K okay as Unix will not allow the date to be set earlier than the Unix epoc, which is 00:00 UCT 1 Jan 1970 on most maintream implementations. This means that years between 72 and 99 are dates in the range 1972-1999, years above 00 will be 2000 & greater. At least until 2038 at the moment on most implementations.

I don't have a large sample to play with but each Unix that do have access to returns "Bad date format" for years prior to the epoc or greater than 38 (2038). And the reason for this is that Unix doesn't keep the "date" internally in the form you might think. It stores the date as the number of tics or seconds since the epoc. This removes any Y2K concerns from the internal timekeeping (Unix was Y2K okay from the git-go), user applications may not have been. At present the only date we have to worry about will be 2038 or there abouts, which would be when the storage for clock ticks (typically a long) will overflow.

Oh yeah, I don't know what Unix you are on, but Solaris, Linux, & Irix optionally allow the specification of the century, Something like: "date [OPTION] [MMDDhhmm[[CC]YY][.ss]] "
tionikAuthor Commented:
Goog Job.
GNU "$date" is now in [mm,dd,tttt,cc,yy].
Focus on    ^
"cc" is for a two digit entry for the century. Such as (19)99 or (20)00.

                    Extremely well done!

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.