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

I would like to show year as 9999 instead 1999, I am using mktime and
ctime, it always shows only 1900 range, can't able to change year only
to 9999, How can I change year to 9999 instead1999?. Thanks in
advance.



> #include <time.h>
> #include <stdio.h>
> int main(void)
> {
> struct tm t = { 0, /* seconds */
> 30, /* minutes */
> 8, /* hours since midnight */
> 1, /* day of month */
> 6, /* months since January */
> 99, /* years since 1900 */
> 0, /* day of week (reset by mktime) */
> 0, /* day of year (reset by mktime) */
> 0}; /* daylight/standard switch */
> time_t c;
> c = mktime(&t);
> printf("%s\n", ctime(&c));
> return 0;
> }

In article
<64fb5935-6728-46ed-ad64-(E-Mail Removed)>,
(E-Mail Removed) wrote:

> I would like to show year as 9999 instead 1999, I am using mktime and
> ctime, it always shows only 1900 range, can't able to change year only
> to 9999, How can I change year to 9999 instead1999?. Thanks in
> advance.

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.

>
>
>
> > #include <time.h>
> > #include <stdio.h>
> > int main(void)
> > {
> > struct tm t = { 0, /* seconds */
> > 30, /* minutes */
> > 8, /* hours since midnight */
> > 1, /* day of month */
> > 6, /* months since January */
> > 99, /* years since 1900 */
> > 0, /* day of week (reset by mktime) */
> > 0, /* day of year (reset by mktime) */
> > 0}; /* daylight/standard switch */
> > time_t c;
> > c = mktime(&t);
> > printf("%s\n", ctime(&c));
> > return 0;
> > }

--
Barry Margolin, (E-Mail Removed)
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 ***

On Apr 22, 6:32*pm, vtan...@gmail.com wrote:

> I would like to show year as 9999 instead 1999, I am using mktime and
> ctime, it always shows only 1900 range, can't able to change year only
> to 9999, How can I change year to 9999 instead1999?. Thanks in
> advance.

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

Chris Burrows wrote:

> That doesn't stop some people from thinking about the Y10K problem:
>
> http://en.wikipedia.org/wiki/Year_10,000_problem

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

http://tools.ietf.org/html/rfc2550

--
Frank Buss, (E-Mail Removed)
http://www.frank-buss.de, http://www.it4-systems.de

Maxwell Lol wrote:
> (E-Mail Removed) writes:
>
>> I would like to show year as 9999 instead 1999, I am using mktime
>> and ctime, it always shows only 1900 range, can't able to change
>> year only to 9999, How can I change year to 9999 instead1999?.
>
> 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]: <http://cbfalconer.home.att.net>
Try the download section.

On Wed, 22 Apr 2009 18:52:49 -0700, David Schwartz wrote:

> 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.

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.

> 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.

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

> Do you know whether 9990 is a leap year or not?

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.

> 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.

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).

On Apr 22, 8:01*pm, gor...@hammy.burditt.org (Gordon Burditt) wrote:

> >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.

> 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.

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

> >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.

> 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.

Not for 7,000 years you can't.

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

> 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.

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

In comp.unix.programmer,comp.arch.embedded,comp.os.li nux.networking,
On Thu, 23 Apr 2009 12:13:43 +0930, "Chris Burrows"
<(E-Mail Removed)> wrote:

>"David Schwartz" <(E-Mail Removed)> wrote in message
>news:27df4e8b-276e-4139-83b9-(E-Mail Removed)...
>
>> 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.
>
>That doesn't stop some people from thinking about the Y10K problem:
>
>http://en.wikipedia.org/wiki/Year_10,000_problem


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.


>
>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 ;-)

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.

Ben Bradley <(E-Mail Removed)> writes:

> 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