I'm doing some programming against the Flickr API and am having problems I've not seen before.  

I uploaded a test picture to Flickr at 10:05:25 AM. 

When I called flickr.photos.getInfo it said the photo had been uploaded at 2:05:25 PM.  

All the dates it had for the picture were 2:05:25 PM, except for "taken" which was correct. Looking at the code, that's the only date that's not transmitted as a Unix date. Its format is like this: 2011-05-19 10:05:25. 

So the Unix date that Flickr sends back, 1305813925, is three hours ahead. What accounts for those three hours? 

This is the code that converts a Unix date to an internal date:

date.set (1, 1, 1970, 0, 0, 0) + number (unixdate) 

I'm thinking it has something to do with the three-hour time diff betw NY and Calif? 

Puzzling... 

How I worked around the problem 

As Jonas explained in the comments, Unix dates have to be UTC-based, and ours are not. So there's a mis-match there. Fixing the encoder, which could easily be done, has the potential of breaking a lot of other apps. There are ways to work around that too, but I'd rather not go there, because I believe I found a workaround. 

When I call Flickr to get new photos, as I loop over them, I compare the upload date of the photo to a previous high-water mark. If it's greater, I reset the mark. Every time I search for new photos, I ask for all the photos since the mark. I don't even bother looking at it, dont' care if it's in the future in my timezone or the past. I just care that it's what Flickr thinks is the correct time.  

What led me to this was a wish that they would just send a token back with the search results that I could send back to them next time. Then they could worry about what it means, and my only job is to store it along with the images I have. I realized I could treat the upload date as if it were such a token. I'm running a full backup now, and will let you know if it worked, but my initial experiment suggests that it will. 

Update: It seems to work.