import uuid, rfc822 print rfc822.formatdate(uuid.uuid1().time/10000000-12219292800)
“rfc822 is ‘Deprecated since [Python] release 2.3”’...”
import uuid, email.utils
print email.utils.formatdate(uuid.uuid1().time/10000000-12219292800)
(Untested, no Python 2.5 here.)
import uuid, email.Utils print email.Utils.formatdate(uuid.uuid1().time/10000000-12219292800).replace('-0000','GMT')From RFC 2616:
All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for time zone, and MUST be assumed when reading the asctime format.
Interesting... there wasn’t a whole lot of text accompanying this code, so I can only take educated guesses as to the utility of this code. It doesn’t help that I’m not particularly conversant with Python. It looks to me that you’re taking a version 1 UUID and extracting the timestamp from it and using it within the Last-Modified HTTP header.
It seems to me that this would typically only be useful if you are also the one generating the UUID. Obviously, you can’t extract a timestamp from anything but a version 1 UUID. And if you’re relying on UUIDs coming from, say, the internet at large, there’s no guarantee that you’ll be getting version 1 UUIDs as opposed to version 4 UUIDs, or worse, things that look like UUIDs but aren’t actually (most likely just a random hex string with hyphens in the right places; I’ve seen this quite a few times). The primary problem being that, like a broken clock that’s right twice a day, random hex strings sometimes end up being indistinguishable from valid UUIDs, only that the data contained within them is completely bogus, so you probably shouldn’t simply ignore the UUIDs that aren’t valid.
I can only take educated guesses as to the utility of this code
I haven’t committed it yet, but basura now uses version 1 UUIDs for _rev values, from which I should soon be able to generate both ETags and Last-Modified headers.
Discovering the magic numbers took me a few minutes, so I figured I would jot it down someplace where I could find it later.
You are a sick, sick man :)
My only concern here is along the lines that Bob brings up; that people will start trying to infer a LM date out of UUIDs that they see in URIs or ETags. Otherwise, very slick.