There are many problems with trying to have a conversation on Twitter.

1. 140 characters can only express very simple ideas.

2. Assembling a chain of messages is hard work. Storify helps, but only if someone is willing to put in the effort. For most things it's not worth it.

3. Yogi Berra: "No one goes there nowadays, it's too crowded." For years social media experts have been writing columns saying the way to make Twitter pay is to "engage" with "key influencers." That means there's a lot of strategic engaging going on. In other words, spam.

4. And Twitter has inadequate defenses against spam. How can you tell if the person at the other end is real or a kid in Guatemala or Malaysia being paid by the message to engage with people to help build cred for some spam-issuing Twitter account? And there's no way to delete a tweet short of blocking the person who sent it. So, as spam gets worse, the block gets wielded more freely.

 5/19/2011; 12:00:00 AM.   .

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.

 5/19/2011; 12:00:00 AM.   .