Box API - The Timestamp type - box-api

Question

I'm trying to upload a file via Box API and I want to specify the content_modified_at parameter. However, I always receive an error in response, saying that I specify the date not in ISO 8601 format. I double-checked the format I'm sending, and it's definitely ISO 8601.
If I don't specify this field, the file is created successfully.
The field in my request has format "2013-04-21T19:39:16+03:00",
and I'm not sure how this is different from "2012-12-12T11:04:26-08:00" that is used in Box API docs
Here is the full listing of my request and response:
-------------- REQUEST --------------
POST https://upload.box.com/api/2.0/files/content
Accept-Encoding: gzip
Authorization: Bearer [hidden]
User-Agent: Google-HTTP-Java-Client/1.14.1-beta (gzip)
Content-Type: multipart/form-data; boundary=__END_OF_PART__
--__END_OF_PART__
Content-Type: application/octet-stream
content-disposition: form-data; name="filename"; filename="file1.txt"
1234567890
--__END_OF_PART__
content-disposition: form-data; name="parent_id"
760503410
--__END_OF_PART__
content-disposition: form-data; name="content_modified_at"
2013-04-21T19:39:16+03:00
--__END_OF_PART__--
-------------- RESPONSE --------------
HTTP/1.1 400 Bad Request
Date: Sun, 21 Apr 2013 17:01:23 GMT
Content-Length: 193
X-Error-Handling: entry;index.php|rid;132352423451741b638d902|runmode;box_api_v2|user;2|user;193761140|
Connection: close
Content-Type: application/json
Server: Apache/2.2.15 (Scientific Linux)
Cache-Control: no-cache, no-store
{"type":"error","status":400,"code":"bad_request","help_url":"http:\/\/developers.box.com\/docs\/#errors","message":"not a valid iso 8601 formatted date","request_id":"132352423451741b638d902"}
UPDATE:
Does anybody of the Box team actually care about this? Does it mean there is a mistake in the services or just nobody wants to explain me what was my fault?

Answer 1

There is an issue with our time stamp parser that we're in the process of fixing.
You should see now issues if you set the timestamp to UTC and send it with a
timezone offset of -00:00, e.g.
2013-04-17T09:12:36-00:00
Again, this is an issue on our end that we're working on resolving.