Dave Winer, 56, is a visiting scholar at NYU's Arthur L. Carter Journalism Institute and editor of the Scripting News weblog. He pioneered the development of weblogs, syndication (RSS), podcasting, outlining, and web content management software; former contributing editor at Wired Magazine, research fellow at Harvard Law School, entrepreneur, and investor in web media companies. A native New Yorker, he received a Master's in Computer Science from the University of Wisconsin, a Bachelor's in Mathematics from Tulane University and currently lives in New York City.
"The protoblogger." - NY Times.
"The father of modern-day content distribution." - PC World.
"Dave was in a hurry. He had big ideas." -- Harvard.
"Dave Winer is one of the most important figures in the evolution of online media." -- Nieman Journalism Lab.
10 inventors of Internet technologies you may not have heard of. -- Royal Pingdom.
One of BusinessWeek's 25 Most Influential People on the Web.
"Helped popularize blogging, podcasting and RSS." - Time.
"The father of blogging and RSS." - BBC.
"RSS was born in 1997 out of the confluence of Dave Winer's 'Really Simple Syndication' technology, used to push out blog updates, and Netscape's 'Rich Site Summary', which allowed users to create custom Netscape home pages with regularly updated data flows." - Tim O'Reilly.
8/2/11: Who I Am.
My 40 most-recent links, ranked by number of clicks.
FYI: You're soaking in it. :-)
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.
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?
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.