Hi. I'm new to the forums, and I have a quick question. I would like to add 14 days to the current system date in a program. Here is my code:

char date[9];
_strdate(date);
char time[9];
_strtime(time);

cout << "The due date of your books is: "
<< date
<< endl;

Read up on localtime() and mktime(), both in time.h

so would you just use something like
time_t mktime(struct tm *time);?

But then how do you add days?

You get a tm struct
You then do something like tm->mday += 14;
then do mktime

so you would do:

struct tm* tm = localtime(&base);
tm->tm_mday += 14;
time_t mktime(struct tm *time);

``````inline time_t addDays(int days)
{
return time(0)+86400*days;
}
time_t printNewDate(int days)
{
std::cout << asctime(localtime(&newtime));
return newtime;
}``````

The time() function declared in <ctime> header returns current time in seconds.
Seconds per day: 24*60*60 == 86400.
Need more?
;)

Ok. I'm officially stupid today.
so you write
{
return time(0)+86400*days;
}
time_t printNewDate(int days)
{
std::cout << asctime(localtime(&newtime));
return newtime;
}

then
cout << asctime(localtime(&newtime)); later when you need to show it

I'm sorry, I can't think

> return time(0)+86400*days;
This is awful, simply awful :(

7.23.2.4 The time function
Synopsis
1 #include <time.h>
time_t time(time_t *timer);
Description
2 The time function determines the current calendar time. The encoding of the value is
unspecified.

Who said time_t must be seconds?

Even then, there are not always 86400 per day either.

Spelled out

``````time_t now = time(NULL);
struct tm* tm = localtime(&now);
tm->tm_mday += 14;
time_t later = mktime(tm);``````

I agree that time_t value may be in other units than seconds. It's a very simple task to scale this value because time_t is an arithmetic type capable of representing times. The "implementation-defined encoding" does not bear a relation to this fact (it's about epoch and granularity).

On the other hand a simple addition to tm_mday may produce wrong dates and the real implementation (VC++ 2008) returns a very strange results after mktime of that "new date". For example, for 2009-02-28 (109,2,28 in tm) we have (109,2,42) in tm and have 2009-02-11 after conversion this funny 2009-02-42 date.

That's one of possible scaling (portable) solutions of my previous approach:

``````/// Get time(0)+Later::days(d) value
class Later
{
public:
explicit Later(int days = 0);
static time_t days(double d = 1.0);
private:
static double scale;
};

namespace {
tm d1 = { 0 };
tm d2 = { 0 };
Later stub;
}

double Later::scale = 0.0;

Later::Later(int days)
{
if (scale == 0.0) {
d1.tm_year = d2.tm_year = 2009 - 1900;
d1.tm_mon  = d2.tm_mon  = 1;
d1.tm_mday = 1;
d2.tm_mday = 2;
time_t t1 = mktime(&d1);
time_t t2 = mktime(&d2);
double tpd = difftime(t2,t1);
scale = tpd / 86400.0;
}
}

time_t Later::days(double d)
{
time_t t;
time(&t);
return t + static_cast<time_t>(86400.0*d*scale+0.5);
}
// Using:
time_t later14 = Later::days(14);``````

>On the other hand a simple addition to tm_mday may produce
>wrong dates and the real implementation (VC++ 2008) returns a
>very strange results after mktime of that "new date".
Granted I don't do a lot of date/time work, but I have yet to see what you've described as a glaring bug in Visual C++'s implementation.

>For example, for 2009-02-28 (109,2,28 in tm) we have (109,2,42) in
>tm and have 2009-02-11 after conversion this funny 2009-02-42 date.
Could you post a full program that exhibits this problem. Does it occur in older versions of Visual C++ as well?

I'm sorry! Mea culpa: I have initialized that damned tm_mon by 2 (march), not by 1 (february) then seen on mday only (11 - right for march 28) :(
I have wrote lots of sensor data approximation/smoothing codes recently, that's why I prefer direct time arithmetics ;)

It worked but I had to change

``````time_t now = time(NULL);
struct tm* tm = localtime(&now);
tm->tm_mday += 14;
time_t later = mktime(tm);``````

to

``````time_t now = time(NULL);
struct tm* tm = localtime(&now);
tm->tm_mday += 14;
cout << asctime(tm);``````

in order for the output to be words, not numbers

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.