471,580 Members | 1,614 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,580 software developers and data experts.

How can I cause the datetime to be the name of the output file.....

Hello everyone,
I realize that I'm new to the group, but I'm hoping that someone might
be able to help me out. What I'm doing is using the GNU 7zip command
line utility to make a backup on my desktop. Essentially, I'm running
an executable that will create a folder, and drop a zipped up copy of
my data to that folder. There doesn't seem to be a way to get 7zip to
automatically create a file where the filename.zip would be a date/time
stamp (something like 020206143260.zip.

What I'd like to be able to do is allow 7.zip to create the file with
some arbitrary name, and then use the rename() function and the time.h
library to somehow grab the current date/time from the computer and
rename the file with the filename being the date/time stamp.

Would time.h be the right library to use? If so, does anyone have any
suggestions as to how a solution might be implemented? Any thoughts
would be greatly appreciated.

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
main()
{

chdir("C:\\Documents and Settings\\All Users\\Desktop\\");
mkdir("Backup");
chdir("C:\\Program Files\\Backup Utility\\");
system("7za.exe a -tzip \"C:\\Documents and Settings\\All
Users\\Desktop\\Backup\\Backup.zip\" \"C:\\Program
Files\\Data\\*.*\"");
chdir("C:\\");

}

Thanks for reading! I've been stumped on this one as I'm relatively
new to C (and programming in general.)

Once again, any help is greatly appreciated.

Feb 5 '06 #1
22 2031

"Merlin" <mr*****@gmail.com> wrote in message
news:11*********************@g44g2000cwa.googlegro ups.com...
Hello everyone,

Merlin? Interesting nick...
Would time.h be the right library to use? If so, does anyone have any
suggestions as to how a solution might be implemented? Any thoughts
would be greatly appreciated.


Yes, it can be.
Yes, I do.

The first thing to consider, before which functions to use, is the time
format and time zone. It would be best if you used military 24-hour time,
so that say a 3pm and 3am file don't have a filename collision. Also, since
Daylight Saving Time shifts the hour by one, it would probably be best to
use a timezone independent time reference such as UTC, GMT, or Zulu time.

If your time.h has strftime(), you could use it with gmtime(). If not, you
can construct a "strftime()" using gmtime() and sprintf().
Rod Pemberton
Feb 5 '06 #2
"Merlin" <mr*****@gmail.com> writes:
I realize that I'm new to the group, but I'm hoping that someone might
be able to help me out. What I'm doing is using the GNU 7zip command
line utility to make a backup on my desktop. Essentially, I'm running
an executable that will create a folder, and drop a zipped up copy of
my data to that folder. There doesn't seem to be a way to get 7zip to
automatically create a file where the filename.zip would be a date/time
stamp (something like 020206143260.zip.

What I'd like to be able to do is allow 7.zip to create the file with
some arbitrary name, and then use the rename() function and the time.h
library to somehow grab the current date/time from the computer and
rename the file with the filename being the date/time stamp.

Would time.h be the right library to use? If so, does anyone have any
suggestions as to how a solution might be implemented? Any thoughts
would be greatly appreciated.

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
main()
{

chdir("C:\\Documents and Settings\\All Users\\Desktop\\");
mkdir("Backup");
chdir("C:\\Program Files\\Backup Utility\\");
system("7za.exe a -tzip \"C:\\Documents and Settings\\All
Users\\Desktop\\Backup\\Backup.zip\" \"C:\\Program
Files\\Data\\*.*\"");
chdir("C:\\");

}


A lot of this (<unistd.h>, 7zip, anything having to do with
directories) isn't covered by standard C, and so is off-topic, but the
core of your question is topical.

Use "int main(void)" rather than "main()".

Check for, and handle, errors on your function calls.

Add a "return 0;" at the end of the program. You might also do a
"return EXIT_FAILURE;" or "exit(EXIT_FAILURE);" if you detect an error
(this requires <stdlib.h>).

Yes, <time.h> is the header (not library) that you want to use to deal
with timestamps. Call time() to get a raw timestamp, type time_t,
then use either gmtime() or localtime() to convert the time_t to a "
struct tm", then use strftime() to generate a string in whatever
format you like.

If you can specify the file name when you invoke the command itself,
you can build a command string using sprintf(); making sure the string
into which you write the formatted is long enough is left as an
exercise.

<OT>
If you care about being able to understand the file names after you've
generated them, you might use a format other than 020206143260.zip,
perhaps something like 2006-02-02-143260.zip; using MMMM-DD-YY also
has the advantage that it sorts nicely in a directory listing.
</OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 5 '06 #3

"Keith Thompson" <ks***@mib.org> wrote
<OT>
If you care about being able to understand the file names after you've
generated them, you might use a format other than 020206143260.zip,
perhaps something like 2006-02-02-143260.zip; using MMMM-DD-YY also
has the advantage that it sorts nicely in a directory listing.
</OT>

One snag is that the American convention (9/11) is different to the British
(11/9). In my opinion months should always include the name, to avoid
confusion.
Feb 5 '06 #4
Keith Thompson wrote:
"Merlin" <mr*****@gmail.com> writes:
I realize that I'm new to the group, but I'm hoping that someone might
be able to help me out. What I'm doing is using the GNU 7zip command
line utility to make a backup on my desktop. Essentially, I'm running
an executable that will create a folder, and drop a zipped up copy of
my data to that folder. There doesn't seem to be a way to get 7zip to
automatically create a file where the filename.zip would be a date/time
stamp (something like 020206143260.zip.

What I'd like to be able to do is allow 7.zip to create the file with
some arbitrary name, and then use the rename() function and the time.h
library to somehow grab the current date/time from the computer and
rename the file with the filename being the date/time stamp.

Would time.h be the right library to use? If so, does anyone have any
suggestions as to how a solution might be implemented? Any thoughts
would be greatly appreciated.

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
main()
{

chdir("C:\\Documents and Settings\\All Users\\Desktop\\");
mkdir("Backup");
chdir("C:\\Program Files\\Backup Utility\\");
system("7za.exe a -tzip \"C:\\Documents and Settings\\All
Users\\Desktop\\Backup\\Backup.zip\" \"C:\\Program
Files\\Data\\*.*\"");
chdir("C:\\");

}

A lot of this (<unistd.h>, 7zip, anything having to do with
directories) isn't covered by standard C, and so is off-topic, but the
core of your question is topical.

Use "int main(void)" rather than "main()".

Check for, and handle, errors on your function calls.

Add a "return 0;" at the end of the program. You might also do a
"return EXIT_FAILURE;" or "exit(EXIT_FAILURE);" if you detect an error
(this requires <stdlib.h>).

Yes, <time.h> is the header (not library) that you want to use to deal
with timestamps. Call time() to get a raw timestamp, type time_t,
then use either gmtime() or localtime() to convert the time_t to a "
struct tm", then use strftime() to generate a string in whatever
format you like.

If you can specify the file name when you invoke the command itself,
you can build a command string using sprintf(); making sure the string
into which you write the formatted is long enough is left as an
exercise.


If your standard library supports it, I suggest the use of snprintf()
instead of sprintf() to take care of unforeseen situations.
<OT>
If you care about being able to understand the file names after you've
generated them, you might use a format other than 020206143260.zip,
perhaps something like 2006-02-02-143260.zip; using MMMM-DD-YY also
ITYM: YYYY-MM-DD Sort of a rotational error...
has the advantage that it sorts nicely in a directory listing.
</OT>


Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Feb 5 '06 #5
Malcolm wrote:

"Keith Thompson" <ks***@mib.org> wrote
<OT>
If you care about being able to understand the file names after
you've generated them, you might use a format other than
020206143260.zip, perhaps something like 2006-02-02-143260.zip; using
MMMM-DD-YY also has the advantage that it sorts nicely in a directory
listing. </OT>

One snag is that the American convention (9/11) is different to the
British (11/9). In my opinion months should always include the name,
to avoid confusion.


<OT>
But the Japanese of YYYY-MM-DD makes the most sense, IMHO, as,
especially on computers sorts nicely and easily... I think this was
suggested by both Michael and Keith, as well.
</OT>

Cheers

Vladimir

--
Politics is like coaching a football team. you have to be smart enough
to understand the game but not smart enough to lose interest.

Feb 5 '06 #6

Vladimir S. Oka wrote:
Malcolm wrote:

"Keith Thompson" <ks***@mib.org> wrote
<OT>
If you care about being able to understand the file names after
you've generated them, you might use a format other than
020206143260.zip, perhaps something like 2006-02-02-143260.zip; using
MMMM-DD-YY also has the advantage that it sorts nicely in a directory
listing. </OT>

One snag is that the American convention (9/11) is different to the
British (11/9). In my opinion months should always include the name,
to avoid confusion.


<OT>
But the Japanese of YYYY-MM-DD makes the most sense, IMHO, as,
especially on computers sorts nicely and easily... I think this was
suggested by both Michael and Keith, as well.
</OT>


it's actually an ISO standard. Google for ISO 8601

--
Nick Keighley

Feb 5 '06 #7
Merlin a écrit :
automatically create a file where the filename.zip would be a date/time
stamp (something like 020206143260.zip.
<...>
Would time.h be the right library to use?
<time.h> is not a library. It's one of the interfaces that allows an
acces to the functions of standard C library.
If so, does anyone have any
suggestions as to how a solution might be implemented? Any thoughts
would be greatly appreciated.


You can build a string representing a curent date/time with

time()
localtime() or gmtime()
strftime()

all declared in <time.h>

--
A+

Emmanuel Delahaye
Feb 5 '06 #8
Rod Pemberton a écrit :
If your time.h has strftime(), you could use it with gmtime().


It must have it if the implementation is compliant to ISO-C90 or more.

--
A+

Emmanuel Delahaye
Feb 5 '06 #9
Thanks Keith,

I realize that much of this is off topic. However, my question was
mostly directed. 7za.exe is an external command line utility that is
being used by my prog. to zip up the appropriate data files.

I thought that since the external had no good way to handle it, that I
could effectively handle this (as you so aptly pointed out) by somehow
generating a string.

Thanks for your excellent answer. I'll review it and see what I can
do. As I'm still learning C, it should prove a most difficult
challenge. I get the general principle, but will let you know when
I've get this implemented.

Also, thanks for clearing me up on the difference between headers and
libraries. I had been thinking that all of my #include's were actually
just declaring the appropriate libraries.

Merlin

Feb 5 '06 #10
Thanks to all for the excellent replies. I'll post another thread on
this topic when I've got something figured out. I really do appreciate
the responses.

Oh, btw, unistd.h was the only way I could figure out to do direct
directory manipulation. The system() call for cd\ just didn't work.

Thanks a ton.

Merlin.

Feb 5 '06 #11
Nick Keighley wrote:
Vladimir S. Oka wrote:
<OT>
But the Japanese of YYYY-MM-DD makes the most sense, IMHO, as,
especially on computers sorts nicely and easily... I think this was
suggested by both Michael and Keith, as well.
</OT>


it's actually an ISO standard. Google for ISO 8601


Didn't know that, thanks!

Cheers

Vladimir

--
Without ice cream life and fame are meaningless.

Feb 5 '06 #12
Keith Thompson wrote:
.... snip ...
<OT>
If you care about being able to understand the file names after you've
generated them, you might use a format other than 020206143260.zip,
perhaps something like 2006-02-02-143260.zip; using MMMM-DD-YY also
has the advantage that it sorts nicely in a directory listing.
</OT>


Using ISO standard YYYY-MM-DD sorts much better. :-) I have yet
to find a year with 9999 months.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Feb 5 '06 #13
Merlin wrote:

Thanks to all for the excellent replies. I'll post another thread
on this topic when I've got something figured out. I really do
appreciate the responses.

Oh, btw, unistd.h was the only way I could figure out to do direct
directory manipulation. The system() call for cd\ just didn't work.


This is the sort of thing you isolate to a separate file, thus
making replacement easy on different systems. C knows nothing
about directories or the care, feeding and upbringing thereof.

<OT> The system call probably worked just fine. However its
effects were limited to the shell execution instance launched by
system. </OT>

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Feb 5 '06 #14
Vladimir S. Oka wrote:
Nick Keighley wrote:
Vladimir S. Oka wrote:
<OT>
But the Japanese of YYYY-MM-DD makes the most sense, IMHO, as,
especially on computers sorts nicely and easily... I think this was
suggested by both Michael and Keith, as well.
</OT>


it's actually an ISO standard. Google for ISO 8601

Didn't know that, thanks!

Cheers

Vladimir

For what it's worth..

/* DateTime in C */
#include <stdio.h>
#include <time.h>

int main(void) {
struct tm tm;
char buf[15];
time_t tim = time(0);
tm = *localtime(&tim);
strftime(buf, sizeof buf, "%Y%m%d%H%M%S", &tm);
puts(buf);
return 0;
}

The Unix/C time stuff does seem cumbersome to me.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Feb 5 '06 #15
"Malcolm" <re*******@btinternet.com> writes:
"Keith Thompson" <ks***@mib.org> wrote
<OT>
If you care about being able to understand the file names after you've
generated them, you might use a format other than 020206143260.zip,
perhaps something like 2006-02-02-143260.zip; using MMMM-DD-YY also
has the advantage that it sorts nicely in a directory listing.
</OT>

One snag is that the American convention (9/11) is different to the British
(11/9). In my opinion months should always include the name, to avoid
confusion.


Which is why I use the ISO 8601 standard date and time notation
whenever possible. For example, the today's date (February 5, 2006)
is represented as 2006-02-05. Since this doesn't look like either the
US (2/5) and British (5/2) notation, there's less risk of it being
confused for either of them. It also avoids depending on any one
language's month names, and it sorts correctly (unlike any notation
that uses month names).

There's a good summary at <http://www.cl.cam.ac.uk/~mgk25/iso-time.html>.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 5 '06 #16
Michael Mair <Mi**********@invalid.invalid> writes:
Keith Thompson wrote:

[snip]
<OT>
If you care about being able to understand the file names after you've
generated them, you might use a format other than 020206143260.zip,
perhaps something like 2006-02-02-143260.zip; using MMMM-DD-YY also


ITYM: YYYY-MM-DD Sort of a rotational error...
has the advantage that it sorts nicely in a directory listing.
</OT>


D'oh! You're right, of course; thanks for the correction.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 5 '06 #17
Joe Wright <jo********@comcast.net> writes:
[...]
For what it's worth..

/* DateTime in C */
#include <stdio.h>
#include <time.h>

int main(void) {
struct tm tm;
char buf[15];
time_t tim = time(0);
tm = *localtime(&tim);
strftime(buf, sizeof buf, "%Y%m%d%H%M%S", &tm);
puts(buf);
return 0;
}

The Unix/C time stuff does seem cumbersome to me.


Just to be clear, does "Unix/C time stuff" refer to the code you
posted? Everything in your program is standard C; there's nothing
Unix-specific about it. (Yes, Unix and C are historically
intertwined; perhaps that's what you meant, but the C standards try to
disentangle them, even while standardizing features that originated
under Unix.)

The output of the program is, for example:
20060205143135
For legibility, I'd change the format string to
"%Y-%m-%d %H:%M:%S"
resulting in
2006-02-05 14:31:35
Or, if I needed to use the result as part of a file name, I might use
"%Y-%m-%d-%H%M%S"
resulting in
2006-02-05-143135
(':' and ' ' characters in file names cause problems on the systems I
use; which characters are allowed in file names is, of course,
entirely system-specific. There may be length constraints as well.)

See also strftime's "%F" conversion specifier, equivalent to
"%Y-%m-%d", and "%T", equivalent to "%H:%M:%S".

A side note: when I started modifying your code, I initially forgot to
change the size of the buffer. I was lucky enough to get some
odd-looking output. This is an illustration of why magic numbers are
a bad idea. If the length of the buffer had been a macro, I would
have been more likely to notice it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 5 '06 #18
"Merlin" <mr*****@gmail.com> writes:
Thanks Keith,

[snip]

Glad I could help. My fee is quite reasonable, I think; just read
<http://cfaj.freeshell.org/google/> and follow its advice.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 5 '06 #19
"Merlin" <mr*****@gmail.com> writes:
Thanks to all for the excellent replies. I'll post another thread on
this topic when I've got something figured out. I really do appreciate
the responses.

Oh, btw, unistd.h was the only way I could figure out to do direct
directory manipulation. The system() call for cd\ just didn't work.


That's not surprising, for reasons best discussed in
comp.unix.programmer.

The <unistd.h> header is not part of the C standard, and is therefore
less portable than the C standard headers, but if you need to use its
features there's nothing wrong with doing so. System-specific or
otherwise non-portable code is perfectly appropriate if it happens to
be what you need (but ideally it should be isolated within your
program); it's just just what we discuss in this newsgroup.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 5 '06 #20
CBFalconer <cb********@yahoo.com> writes:
Keith Thompson wrote:

... snip ...

<OT>
If you care about being able to understand the file names after you've
generated them, you might use a format other than 020206143260.zip,
perhaps something like 2006-02-02-143260.zip; using MMMM-DD-YY also
has the advantage that it sorts nicely in a directory listing.
</OT>


Using ISO standard YYYY-MM-DD sorts much better. :-) I have yet
to find a year with 9999 months.


Some of them just seem that way.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 6 '06 #21
On Sun, 5 Feb 2006 08:56:18 +0000 (UTC), "Malcolm"
<re*******@btinternet.com> wrote:

"Keith Thompson" <ks***@mib.org> wrote
<OT>
If you care about being able to understand the file names after you've
generated them, you might use a format other than 020206143260.zip,
perhaps something like 2006-02-02-143260.zip; using MMMM-DD-YY also
has the advantage that it sorts nicely in a directory listing.
</OT>

One snag is that the American convention (9/11) is different to the British
(11/9). In my opinion months should always include the name, to avoid
confusion.

Usually there are other considerations more important than
readability. Sorting, for example, where you probably want
YYYYMMDDhhmm.

--
Al Balmer
Sun City, AZ
Feb 6 '06 #22
Keith Thompson wrote:
Joe Wright <jo********@comcast.net> writes:
[...]
For what it's worth..

/* DateTime in C */
#include <stdio.h>
#include <time.h>

int main(void) {
struct tm tm;
char buf[15];
time_t tim = time(0);
tm = *localtime(&tim);
strftime(buf, sizeof buf, "%Y%m%d%H%M%S", &tm);
puts(buf);
return 0;
}

The Unix/C time stuff does seem cumbersome to me.

Just to be clear, does "Unix/C time stuff" refer to the code you
posted? Everything in your program is standard C; there's nothing
Unix-specific about it. (Yes, Unix and C are historically
intertwined; perhaps that's what you meant, but the C standards try to
disentangle them, even while standardizing features that originated
under Unix.)

The output of the program is, for example:
20060205143135
For legibility, I'd change the format string to
"%Y-%m-%d %H:%M:%S"
resulting in
2006-02-05 14:31:35
Or, if I needed to use the result as part of a file name, I might use
"%Y-%m-%d-%H%M%S"
resulting in
2006-02-05-143135
(':' and ' ' characters in file names cause problems on the systems I
use; which characters are allowed in file names is, of course,
entirely system-specific. There may be length constraints as well.)

See also strftime's "%F" conversion specifier, equivalent to
"%Y-%m-%d", and "%T", equivalent to "%H:%M:%S".

A side note: when I started modifying your code, I initially forgot to
change the size of the buffer. I was lucky enough to get some
odd-looking output. This is an illustration of why magic numbers are
a bad idea. If the length of the buffer had been a macro, I would
have been more likely to notice it.

Thanks for the critique. The code was meant to be one example to how to
do it. The code is correct as far as I know and is a valid example.

The format string does exactly what I want. I think %F might be C99
specific. I start with C89.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Feb 7 '06 #23

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Harald Hanche-Olsen | last post: by
5 posts views Thread by Tom | last post: by
9 posts views Thread by Tom | last post: by
reply views Thread by vooose | last post: by
9 posts views Thread by Phil B | last post: by
3 posts views Thread by INeedADip | last post: by
reply views Thread by XIAOLAOHU | last post: by
reply views Thread by leo001 | last post: by
reply views Thread by lumer26 | last post: by
reply views Thread by Vinnie | last post: by
1 post views Thread by lumer26 | last post: by
reply views Thread by lumer26 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.