Perl DateTime objects, time zones, and ISO8601
13 April 2006
in blog
tagged with
[date]
[perl]
[time]
Here’s what I want to do. DateTime objects conveniently stringify to their ISO8601 date representation. But last week the clocks changed, and all my code broke, because this representation doesn’t include the time zone. I want a DateTime object that will stringify to an ISO8601 date including a timezone. Shouldn’t be too hard.
uneval() does not produce JSON
22 April 2006
in blog
tagged with
[javascript]
[programming]
More playing with JSON and Spidermonkey has revealed yet another incredibly annoying fact (I hate those guys). Spidermonkey provides a lovely uneval() function, that does the exact opposite of eval() - turns JS objects into strings. It works on almost everything, and make life very very nice. There’s also Object.toSource() which does something similar (but not the same - try uneval("") vs "".toSource()).
But the strings that uneval produce are not valid JSON, as I have been assuming. I’ve been getting steadily more worked up at all the JSON parsers in the world, refusing to parse things that are clearly valid JavaScript, and eventually I go look at the spec, which fails to list ' as a valid string delimiter. And guess what delimiter uneval produces? Yay. So all the parsers are fine, and it’s just SpiderMonkey that’s broken.
Fortunately, Mochikit provides a nice serializeJSON() function.
On blog comment spam
28 April 2006
in blog
tagged with
[blog]
[comments]
[spam]
Blog comment spam, the scourge of the internet. Having written yet another CMS to power jerakeen.org, I wanted comments on pages again. Django rocks hard - adding commenting was easy. And a day later, I have comment spam. Bugger.
JavaScript string weirdness
29 April 2006
in blog
tagged with
[javascript]
[programming]
Recently, I mentioned a peculiar difference between uneval and toSource. Specifically (using the SpiderMonkey JS console):
js> uneval("");
""
js> "".toSource();
(new String(""))
"" and new String("") are different types of objects. The first is the basic string type, and only really has a value. The second is a full Object, that happens to have a value. However, it turns out that if you treat a basic string type as an Object, say by putting ‘.’ after it in an expression, the SpiderMonkey runtime will implicitly promote the string to a String. Hence, "".toSource() promotes the string object, then calls toSource on the new String object.
Annoyingly, the String Object doesn’t hang around, it’ll get thrown away as soon as you’re done with it. This leads to the weird case that you can set attributes on a basic string type (because it’ll get promoted to an Object, and Objects have attributes) but they don’t stay set (because the Object you’ve set them on gets thrown away as soon as the set call finishes).
By the way, all of this applies very specifically to the current CVS trunk SpiderMonkey. I don’t know what most web browser engines do with strings, so don’t assume this applies in, say, Internet Explorer. But I’d be interested if someone wants to find out and tell me…