I need to show time of the year as 9999 instead 1999

If you're on a system where time_t is 32 bits, the highest date it can represent is in the year 2038.

If you have a 64-bit time_t, you should be able to put 8099 in the tm_year member to get the year 9999.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Your question doesn't make any sense. Why don't you try again?

The 'ctime' function implicitly converts to local time prior to making the time printable. I don't know where you live, but where I live, we have no rules for those years.

Simply put, nobody alive today could possibly know how many seconds it will take to get from 1/1/70 00:00:00 GMT to any time in the year

9999. So there is literally no way to write time functions that convert from elapsed times to wall times.

Do you know whether 9990 is a leap year or not? Of course, nobody does, since it will depend on the rate at which the Earth's rotation slows, assuming we even use Earth-based time then.

DS

That doesn't stop some people from thinking about the Y10K problem:

Fortunately (assuming the retiring age doesn't continue to creep up) I won't have to worry about it as I'll have retired by then ;-)

-- Chris Burrows CFB Software Armaide: LPC2000 Oberon-07 Development System

Once upon a time, I was working at a financial company that had to model some rather long-duration instruments. We were already hitting the 2038 problem.

We started using a toolkit from Rogue Wave which included a Date class that was just that; no time. We'd spent enough time thinking about 2038, and people were talking more and more then about Y2K, that I had to write a little whitepaper preparing for when the Date class would roll over.

I think it worked out to about the year 300,000.

Foolishly, I completely failed to account for the slowing of the Earth's rotation in that paper. I'm sure that that will come back to haunt me.

- Andrew

You have no guaranteed rules for the year 2010, either, as there's no guarantee that governments won't muck with daylight savings time, time zones, leap seconds, leap years, and changing to 37 1/2 months per year.

The same applies to any time in the year 2010. Or tomorrow. However, you can extend the current rules, assuming no one will change them (at least much) and get a pretty good approximation.

That's true of any future time. But people try to do it anyway, for example, in storing the date when you're going to be eligible to retire, etc.

This can be generalized, to provide a solution for the Y10**30 problem and beyond :-)

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

I wish you luck in writing code that will perform some function in

7000 years. I do think you are extremely optimistic.

:-)

Of course if he should describe his real problem, instead of his imagined solution, he might get some real suggestions. As it is his only effect has been to create ribald hilarity in the group.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

You just assume that the last known rules will continue indefinitely. You don't know for certain when DST will end *this* year; I don't know of any country whose constitution limits the state's ability to change DST rules at short notice.

Unix' time_t assumes 60-second minutes; a leap second just causes time() to return the same value for 2 consecutive seconds.

It isn't, as it isn't a multiple of four. If you had asked whether 9990

*will* be a leap year, that would be a prediction involving some degree of uncertainty. But right now, 9990 isn't a leap year.

Even if the rotation/orbit ratio changes, there's no reason for 9990 to be a leap year. Any adjustments would likely be performed by changing the leap year status of a year which is divisible by 4, e.g. making the year

3000 a leap year or the year 4000 a common (non-leap) year.

It's certainly possible that the number of leap days between now and 9999 will change from current assumptions, but that doesn't mean that you can't convert a time_t to a struct tm using the current assumptions (and that's exactly what e.g. gmtime() or localtime() will do, provided time_t is large enough).

That's correct. Extension of local time to the future is always a problem.

,

Not for 7,000 years you can't.

Nobody tries, sensibly, to extend the time for 7,000 years.

That's like saying that because people can predict how many people will go the beach tomorrow they can predict how many people will go to the beach in 1,000 years. No, nobody can do that.

There is no hard boundary, but it is quite clear that next week is quite sensible and 5,000 years from now is completely senseless.

DS

That article mentions the Long Now Foundation, which in preparing for Y10K (and to design that big clock) already uses five digits for a year.

I'm worried that I may have to work until Y10K to pay off the debt and interest from recent years of US Government spending.

Be happy you have a job. It is not guarenteed, and part of the reason may be that govt spending