I would like to mark this as a duplicate of bug #56443, because the
timestamp is part of the EXIF metadata.  Or this could be marked as a
duplicate of bug #61499, which relates to the user interface for
editing the metadata.  What do you think?

this idea came to me when i was viewing an image that NASA had fiddled
with in 1993 (with xv).  i knew that because it was in the jpeg
comment.   also, i don't understand exif stuff, but does that mean
that only the new style jpeg will have such info? 

Carol, the comment you saw was in the .xvpics thumbnail, not in the
JPEG it referred to.

okay, what ever caused me to see the date that the image was made and
the app that made it ....

it would be nice if gimp could do this without having to buy a camera
to have the exif info to get it.

this is a frustrating forum.

Huh?  You do not need a digital camera to add metadata to your images.
You only need a program that can edit it whenever you want.  If/when
the GIMP is able to edit (bug #61499) and understand EXIF metadata
(bug #56443) or XMP/IPTC metadata (bug #94416), then you will be able
to edit the creation date easily.

The metadata could be stored in the following image formats: XCF, PNG,
JPEG and TIFF.

We could also add an option to include a time stamp in the comment so
that it could be added to other image formats that have comments but
do not have better ways to store metadata, such as GIF and TGA (but
see bug #95928 that I just reported).

So the two options for this bug report are:
- confirm it and leave it open (mainly for GIF)
- mark it as a duplicate of one of the bug reports mentioned above

It would be a good idea to extend the default comment to support
format string like markers, with interpolation for stuff like time
stamps and the like. That way, the plugins that use the default
comment get it for free.

Hmmm...  OK, I will leave this open, then.  But I do not think that it
would help much: the plug-ins that want to use the timestamps and other
stuff would have to be modified so that they can understand that the
"<timestamp>" marker in the comment is a timestamp, and so on.  How
would this be different from telling the plug-ins to use one parasite
for gimp-comment and another one for gimp-timestamp, and so on?  I'd
rather have a solution in which each metadata item goes into its own
parasite so that the save plug-ins do not have to parse the comment
field in order to extract the relevant information that should be saved
in the file.

No, I mean the file formats that have only one generic comment field
that use the "gimp-comment" parasite already would get that for free.
Gimp itself would do the interpolation when setting the parasite.

When we address the other bugs, file formats that want to be aware of
distinct fields for metadata would use an alternate interface.

I understand, but this is going to be a bad hack and I would like to
avoid that.  The EXIF and XMP/IPTC formats include a field for
comments.  So if you load an image (say, GIF) containing a comment and
then save it to a new file that supports EXIF or XMP, the new file
should have its comment copied from the old file (without any
changes).  Of course, in addition to that, some other metadata fields
will be set automatically: timestamp, software used, etc.

Doing some interpolation behind the scenes could break that.  Why
should there be a special case for "gimp-comment" and not for other
parasites?  The only way to make this work without side effects would
be to do the interpolation only on the default comment at the time
it is entered by the user, but never touch the comment after that.
But then this would not be interesting if the goal is to have a
current timestamp.  So then we would probably need some other
parasite (or an internal variable) that tells the GIMP if the comment
is still the default one or if it has been loaded from a file or
edited in any way, so that it knows when it should do the
interpolation or not.

Maybe you have a better solution than what I just described, but I
think that the idea of getting the timestamp "for free" will either
introduce some annoying side effects or require some changes in all
plug-ins (making this not really "for free").  The effort may be a
bit lower than for implementing the EXIF spec, but maybe not much
lower (assuming that we want this to work correctly).

Changes at the request of Dave Neary on the developer mailing list.  
I am changing many of the bugzilla reports that have not specified a target
milestone to Future milestone.  Hope that is acceptable.  

Resolving as WONTFIX because it is clear by now that this suggestion is not going to be followed.  It is not entirely unreasonable, but there are better ways -- and the bug report has been sitting ignored for four years anyway.

Until there is acted on or there is a reasonable alternative, this bug 
needs to remain open.

Sorry, but it is our right to close bugs as WONTFIX if we decide that we don't like the suggested change. Carol, please respect that and leave the bug closed.

A reasonable alternative is to create a plug-in that adds a customizable comment to the image. Make it possible to run it non-interactive, assign a shtocut, and thus update the comment (which may include any kind of metadata you can access) on demand.

This bug can remain closed nevertheless, IMO.

If you look at comment #11 what it is really saying is that putting enhancements on bugzilla is useless.

All of those years of "put it on bugzilla so that we remember"...it is not even hogwash.

If you could actually take the time to decide that it is an unliked change, then that is fine.  There was no discussion which lead to that conclusion, however.

I could just as easily reopen the bug because "it had been decided that it was a good idea but there were no decision makers on what way to do this" and it would be much more accurate.