Thanks for all your work,
I've been away for a long time and just successfully upgraded to 1.2 from a 1.1.5 (?)
I think this problem was also occurring in 1.5 - but i'm sure it was fixed at one point in the previous versions, since i had started this topic
http://www.zenphoto.org/support/topic.php?id=1924
and it was resolved.

This is how flickr implies "date taken" and "date uploaded" in their rss feed;

<pubDate>Mon, 15 Sep 2008 15:42:53 -0800</pubDate> <dc:date.Taken>2008-08-29T17:03:08-08:00</dc:date.Taken>

(and this feed was called today Sept 17)
So maybe we can have both without one interfering with the other?
I always notice the feed date since i aggregate my site feeds into one and when the image feed is historically falling behind or random - i know somethings up.

Thanks again for your hard work!
all is appreciated

Actually the rss feed uses mtime to sort the image entries. But I just saw that the <pubDate> part indeed uses 'date' instead of 'mtime'. Not sure this was a mistake or on purpurse. I guess we could use <dc:date.taken>, too. I will take a look.

I understand from this post
http://www.zenphoto.org/support/topic.php?id=2014#post-11843
that mtime is the unique image file's last modification date on the server - which could presumably be 'upload date' if nothing crazy happens, or if you guys don't add native editing features in the future.
But just for my information, so besides mtime, there is no database variable for the upload date alone? That wont be affected by random server actions (theoretically speaking).

@ on purpose
you know the problem with sorting by the 'date' variable (which i figured out shows the exif date taken) is that if you upload an old photo, the person that is following your image feed will never be updated - because the item is older than the others the feed reader is publishing.

Correct. mtime is the file modification date that we used for sorting within the feed so that older taken but newly uploaded images don't fall behind. I am not a photographer so I don't really use exif info. But the date field in the db is either filled with the mtime value or if exists with the exif date value. If I recall that correctly.
The database variable for the upload time/order or more correctly the time when Zenphoto discovered the image would be the id.

We could change the 'date' in line 135 of the feed's <pubDate> to 'mtime' if that solves that. As I said we might just have forgotten to change that. Also you can alway customize it to your liking. You could also change the sortorder in line 108 if you like to use the ID.

{edit / reading your comments update}

Great explanation!
So from what i understand; for a feed describing newly additions to a Zp gallery (which is what most feeds describe - newly aditions), wouldn't it be more correct to use the id instead of the mtime?

I could also presume this logic for a recent uploads page.

i'll experiment with your new suggestions and get back to you with the results

We had originally the id for sorting but several users "complained" that it does not match the order of photos taken, so we changed it. Maybe we should consider to make the feed order an option..

Thank you,

Well about the sorting; @ to anyone who is opposed to this
the sole purpose of a news feed is to serve "new additions" with a date of "publication", replacing the need to visit the site constantly to see whats new.
So with that said, sorting in a news feed, i believe is best done with "id" (which reflects publication date).

Implementing this with mdate could also provide almost similar results but it is not exactly what is needed, since it could duplicate posts in the readers RSS feed, if by chance a small thing like crop was fixed and re-uploaded by the same file name.

@ "order of photos taken" can never be a RSS feed sort since, news aggregation (online or desktop) is sorted by date "posted" and is compared to _Today_ and thus your feed will be almost useless - unless you always upload VERY promptly. Yet i still don't understand why anyone would want this function.

Anyways!
thank you for the suggestions, i tried multiple combinations of all of them;

@ change the 'date' in line 135 of the feed's <pubDate> to 'mtime'
> echo fixRSSDate($images['mtime']);
gave me "Thu, 01 Jan 1970 00:00:00 +0000" for the <pubDate> in all image entries

So i'm guessing that the "fixRSSDate" function doesn't work with mtime format (?)

I also tried

@sortorder in line 108 if you like to use the ID.

Yet then realized that, that would only be efficient if the <pubDate> was also reflecting the corresponding "id" date.

I confirm that this line of code 108
" ORDER BY images.id DESC LIMIT ".$items);
works though, without any errors.

I wish i could hack this myself, but it seems its not just a quick hack..

Ideally i would think sorting and publishing (pubDate) by id and using the id's corresponding date value would be most systematically correct for a news feed. If not that, mtime at least.

Thank you for your consideration and time!

duplicated entries: Not really because Zenphoto is file system based, what is not there is not taken.
This also leads to the next internal of Zenphoto. The date uploaded is not always the date Zenphoto discovers an image! If you upload an image via ftp and you don't visit that yourself, precache or someone else visits that image then it can be the Zenphoto discoverse it days after the upload (theoretically).

That's why we started using mtime. There is no corresponding date to the id yet. But maybe it would be possible to implement that.

[i]gave me "Thu, 01 Jan 1970 00:00:00 +0000" for the <pubDate> in all image entries
So i'm guessing that the "fixRSSDate" function doesn't work with mtime format (?)[/i]
Oh, yes, sorry, of course, that functions does not work with it.

yes yes, duplicate rss entries will not be produced,
yet the desktop/web RSS reader will create a new entry for the previous (but newly updated entry) due to modification date that is reflected in the pubDate) item.

in short,
you upload an image - it is served via feed
feed readers pick it up

Two weeks later, you think it looks better flipped so you mirror it but decide to upload it as the "same" file and not an individual new update. (i presume by what i have understood - do correct me if i am wrong!) mtime will be changed, consequently so will pubDate, thus a new feed item will be picked up / or an old feed item will reappear at the top of the reader's news feed that day.

I think this is unproductive, since if an artist wants to publish a separate new version of an image, they would not overwrite the previous.

[i]"If you upload an image via ftp and you don't visit that yourself"[/i]

YES!
i have always wondered about this!
Couldn't Zp revisit the site album folder at least once at the end of each day?
this would be excellent!

[i]There is no corresponding date to the id yet. But maybe it would be possible to implement that.[/i]

That would be beautiful!

Thanks for your hard work and time!

any plans to address any of these problems / proposals?
just to ask

thank you for your consideration!

We are considering everything...:-) No, seriously, 1.2.1 is due end of the months and it will not make it into that because we have a feature freeze next week so that our translator have some time to match up.

To your questions from above:
Regardng the reupload of a altered image I actually would want a new entry for that since it's basically a new image I want to get noticed.

For the automatic visiting of albums by Zenphoto: This is just not the way it works, Zenphoto uses the principle of lazy evaluation, which means data is only fetched if requested. The workaround for that is precaching or visiting the albums yourself (also uploading via admin does basically the same).

For the date on upload matching the id please open a ticket. We will talk about that.

honestly i disagree! for the above reasons and because it goes against what the *web user* is accustomed to.

No application I know of, republishes items when they are edited/modified.
Yet, this does not mean a person can not re-Syndicate a revision, by all means upload it as a New individual file.
Yet it does restrict an artist from silently correcting his work

So "new image" i think actually refers to a "new file" in a file based system.

But that's only my opinion, i'm currently trying to fix the feed pubDate myself.

I think a 'date_added' field would be a good one to have, for both albums and images.

We should not use the mtime for the published time, as you say that's not what's expected, modified files should not be 'republished'.

Thanks.

Thank you trisweb and acrylian!

by replacing line 135
i'm temporarily using mdate as the publication date - but looking forward to when the 'date_added' field is implemented; as a constant publication date.

`<pubDate><?php echo date('D, d M Y g:i O',$images['mtime']); ?></pubDate>`

i think this also relieves the need for the fixRSSDate function lines 7 - 18 since i didn't see it used elsewhere.

just as a suggestion, maybe the 'id' variable could serve dual purpose if it was date based; YYYYMMDDhhmmss
and made sure it was always unique, which probably the 'seconds' counter would determine in multiple uploads. Of course this would require a database data correction in the upgrade process if it is ever implemented for the future Zp versions.

I'm not sure of how Zp uses the id, so i don't really know if this will be efficient!
goodluck!