__DATE__ macro

[thomas]

Hi,

I'm using date as module version like this:
-----
#define MAJOR_VERSION 1
char strVersion[32];
sprintf(strVersion, "%d.%s", __DATE__);
----
And finally I got "1.Oct 19 2010" as version.
But I expected "1.2010.10.19", or "1.10.19.2010", something like that.
How to do it elegantly?

One way I can think of is to parse the __DATE__ string and compose the
version string to my own need,
though I expect there might be a way to set the date format so that
extra code is minimal.

Thanks.

tom

 

[Marc]

Hi,

I'm using date as module version like this:

Aren't you missing an argument here?

----
And finally I got "1.Oct 19 2010" as version.
But I expected "1.2010.10.19", or "1.10.19.2010", something like that.
How to do it elegantly?

One way I can think of is to parse the __DATE__ string and compose the
version string to my own need,
though I expect there might be a way to set the date format so that
extra code is minimal.

If you don't want to parse the string at runtime, you'll have to use
some external tool. On Unix: g++ -DMYDATE=`date +%Y.%m.%d` ...
I don't know about windows.

 

[Gernot Frisch]

sprintf(strVersion, "%d.%s", __DATE__);
But I expected "1.2010.10.19", or "1.10.19.2010", something like that.

// Like this?
char mnames[] = {"JanFebMarAprMayJunJulAugSepOctNovDec"};
char today[256];
char temp[8];
int day, month, year;
double version;
strcpy(today, __DATE__); // Date of compilation
for (day=0; day<3; day++) temp[day]=today[day];
temp[3]='\0';
month=(int)(strstr(mnames, temp)-mnames)/3 +1;
day=atoi(&today[4]);
year=atoi(&today[strlen(today)-5]);

 

[Goran]

Hi,

I'm using date as module version like this:
-----
#define MAJOR_VERSION 1
char strVersion[32];
sprintf(strVersion, "%d.%s", __DATE__);
----
And finally I got "1.Oct 19 2010" as version.
But I expected "1.2010.10.19", or "1.10.19.2010", something like that.
How to do it elegantly?

One way I can think of is to parse the __DATE__ string and compose the
version string to my own need,
though I expect there might be a way to set the date format so that
extra code is minimal.

You need to check your compiler for that, I guess. I'd be hugely
surprised if C or C++ standard specified the format of the date. At
the very least, I would expect that compiler puts in said date in an
appropriate locale format. Different language, too. But AFAICanSee,
GCC docs isn't very specific on the format, and MS says format is
whatever asctime function says. Oh well, I guess I was expecting too
much ;-).

That said, perhaps you aren't using the best way to represent version?
Other approach people use is to "encode" date into version numbers.

Goran.

 

[James Kanze]

I'm using date as module version like this:
-----
#define MAJOR_VERSION 1
char strVersion[32];
sprintf(strVersion, "%d.%s", __DATE__);
----
And finally I got "1.Oct 19 2010" as version.
But I expected "1.2010.10.19", or "1.10.19.2010", something like that.
How to do it elegantly?
One way I can think of is to parse the __DATE__ string and
compose the version string to my own need, though I expect
there might be a way to set the date format so that extra
code is minimal.

You need to check your compiler for that, I guess. I'd be hugely
surprised if C or C++ standard specified the format of the date.

The standard specifies the format "Mmm dd yyyy". Which is a bit
strange to me.

At the very least, I would expect that compiler puts in said
date in an appropriate locale format.

The standard doesn't allow it. It requires the US format
above, with three letter month abbreviations in English.

 

[Victor Bazarov]

I'm using date as module version like this:
-----
#define MAJOR_VERSION 1
char strVersion[32];
sprintf(strVersion, "%d.%s", __DATE__);
----
And finally I got "1.Oct 19 2010" as version.
But I expected "1.2010.10.19", or "1.10.19.2010", something like that.
How to do it elegantly?
One way I can think of is to parse the __DATE__ string and
compose the version string to my own need, though I expect
there might be a way to set the date format so that extra
code is minimal.

You need to check your compiler for that, I guess. I'd be hugely
surprised if C or C++ standard specified the format of the date.

The standard specifies the format "Mmm dd yyyy". Which is a bit
strange to me.

Why is it strange? It's basically a verbatim copy of the definition C90
has, AIUI.

The standard doesn't allow it. It requires the US format
above, with three letter month abbreviations in English.

Actually, the Standard's description does say "If the date of
translation is not available, an implementation-defined valid date shall
be supplied." There is no elaboration what might "not available" mean,
so I think it's *possible* to have a locale-driven date, as long as it
is "valid".

V

 

[Gennaro Prota]

I'm using date as module version like this:
-----
#define MAJOR_VERSION 1
char strVersion[32];
sprintf(strVersion, "%d.%s", __DATE__);
----
And finally I got "1.Oct 19 2010" as version.
But I expected "1.2010.10.19", or "1.10.19.2010", something like that.
How to do it elegantly?
One way I can think of is to parse the __DATE__ string and
compose the version string to my own need, though I expect
there might be a way to set the date format so that extra
code is minimal.

You need to check your compiler for that, I guess. I'd be hugely
surprised if C or C++ standard specified the format of the date.

The standard specifies the format "Mmm dd yyyy". Which is a bit
strange to me.

Last time I looked at a C rationale (I don't recall if it was
the C90 or the C99 one, although that shouldn't change anything)
it explicitly said that they chose a specific format to aid in
parsing.

(The rationale is a great thing that C++ should have too.)

 

[Alf P. Steinbach /Usenet]

* Gennaro Prota, on 20.10.2010 17:25:

Last time I looked at a C rationale (I don't recall if it was
the C90 or the C99 one, although that shouldn't change anything)
it explicitly said that they chose a specific format to aid in
parsing.

(The rationale is a great thing that C++ should have too.)

Is the C rationale available anywhere like, sort of, free, like, say, a draft,
or just, like, free?


Cheers,

- Alf

 

[Ian Collins]

* Gennaro Prota, on 20.10.2010 17:25:

Is the C rationale available anywhere like, sort of, free, like, say, a
draft, or just, like, free?

I hate to say it Alf, but GIYF!

www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf

 

[LR]

* Gennaro Prota, on 20.10.2010 17:25:

Is the C rationale available anywhere like, sort of, free, like, say,
a draft, or just, like, free?

Looks like links are here:
http://www.open-std.org/jtc1/sc22/wg14/

LR

 

[Alf P. Steinbach /Usenet]

* Ian Collins, on 21.10.2010 06:56:

I hate to say it Alf, but GIYF!

www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf

Thanks!

- Alf (oops, "article rejected: [thank you]")

 

[James Kanze]

I'm using date as module version like this:
-----
#define MAJOR_VERSION 1
char strVersion[32];
sprintf(strVersion, "%d.%s", __DATE__);
----
And finally I got "1.Oct 19 2010" as version.
But I expected "1.2010.10.19", or "1.10.19.2010", something like that.
How to do it elegantly?
One way I can think of is to parse the __DATE__ string and
compose the version string to my own need, though I expect
there might be a way to set the date format so that extra
code is minimal.
You need to check your compiler for that, I guess. I'd be hugely
surprised if C or C++ standard specified the format of the date.

The standard specifies the format "Mmm dd yyyy". Which is a bit
strange to me.

Why is it strange? It's basically a verbatim copy of the
definition C90 has, AIUI.

Yes, but the definition in C90 is strange. One would expect
something internationalized, either dependent on the current
locale (where the code is compiled) or more likely, and
international format, like ISO.

Actually, the Standard's description does say "If the date of
translation is not available, an implementation-defined valid
date shall be supplied." There is no elaboration what might
"not available" mean, so I think it's *possible* to have
a locale-driven date, as long as it is "valid".

Well, valid means that the US month abbreviations are used, and
that the month comes before the day.

 

[James Kanze]

On 20/10/2010 14.17, James Kanze wrote:

[...]

Last time I looked at a C rationale (I don't recall if it was
the C90 or the C99 one, although that shouldn't change anything)
it explicitly said that they chose a specific format to aid in
parsing.

In which case, the ISO format would seem indicated. Having
month names (rather than numbers) doesn't facilitate parsing.
And the ISO format is not so US-centric.