Defect #19354

Unexpected milliseconds in JSON time attributes

Added by Alex Last over 7 years ago. Updated over 7 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:Jean-Philippe Lang% Done:


Category:REST API
Target version:3.0.1
Resolution:Fixed Affected version:


our original request #5901 was about exposing Redmine version through REST API so that clients would know what functionality is supported by the server.
that request is still relevant, but I decided to submit a smaller feature request about date formats.

Redmine 3.x broke backward compatibility - the date format used in REST responses is different from Redmine 2.6:

From redmine 2.6.0: "updated_on":"2015-01-23T00:15:24Z"
From redmine 3.0.0: "updated_on":"2015-01-29T10:06:19.000Z"

one of our users submitted this bug report:

if we could query Redmine to see its version, we could pick the right date format instead of guessing... now we will have to check "are there 3 more digits after this and before that?"..

but a better option would be querying Redmine to see what date format it uses for long dates and short dates - because this is what the library actually cares about.

Associated revisions

Revision 14101
Added by Jean-Philippe Lang over 7 years ago

Don't include milliseconds in JSON API responses (#19354).


#1 Updated by Jean-Philippe Lang over 7 years ago

  • Status changed from New to Needs feedback
  • Assignee set to Jean-Philippe Lang

The date format is not supposed to change in 3.0.0. There was a problem that is fixed for 3.0.1 (#19065), but it was different. Here is what I get for an issue with current trunk:


Can you give more details about how to reproduce this?

#2 Updated by Jean-Philippe Lang over 7 years ago

Redmine uses #xmlschema without arguments to format dates in XML output, which gives 0 decimals by default:

=> "2015-03-14T09:04:32Z" 
=> "2015-03-14T09:04:41.221Z" 


#3 Updated by Alex Last over 7 years ago

Note that I am using JSon instead of XML.

This is my Redmine 3.0.0 on the test server:
(use "test"/"test" credentials).

the payload it returns is

  "issue": {
    "id": 2,
    "project": {
      "id": 11,
      "name": "permanent test project" 
    "tracker": {
      "id": 1,
      "name": "Bug" 
    "status": {
      "id": 1,
      "name": "New" 
    "priority": {
      "id": 2,
      "name": "Normal" 
    "author": {
      "id": 1,
      "name": "Redmine Admin" 
    "subject": "test123",
    "description": "",
    "done_ratio": 0,
    "spent_hours": 0.0,
    "custom_fields": [
        "id": 1,
        "name": "my_custom_1" 
        "id": 2,
        "name": "custom_boolean_1",
        "value": "" 
        "id": 3,
        "name": "custom_multi_list",
        "multiple": true,
        "value": [
    "created_on": "2015-03-12T20:10:27.000Z",
    "updated_on": "2015-03-12T21:46:21.000Z" 

server info:

  Redmine version                3.0.0.stable
  Ruby version                   2.0.0-p598 (2014-11-13) [x86_64-linux]
  Rails version                  4.2.0
  Environment                    production
  Database adapter               Mysql2
  Git                            1.9.1
Redmine plugins:
  no plugin installed

even if you change Json format to match XML now, Redmine 3.0.0 version will still have this other format...
how can external clients detect the proper format? one way is to search for "." in the date string and thus detect that there are milliseconds there.
but a better (much more resilient) way would be for the server to provide the formatting string either in a separate REST endpoint ("give me all server settings please") or - even better - right inside the "issues/issue/all others" response:
"hey, you asked for issues, here is the result, and by the way, the date format I use is xxx-xxx-xxx-xxx-..."- this would make the response much easier to understand and client libraries (like Redmine Java API) - easier to maintain.

#4 Updated by Jean-Philippe Lang over 7 years ago

  • Tracker changed from Feature to Defect
  • Subject changed from expose all date formats used by Redmine REST API to Unexpected milliseconds in JSON time attributes
  • Status changed from Needs feedback to Resolved
  • Target version set to 3.0.1
  • Resolution set to Fixed

This change was not intentional, this was changed by Rails 4. So the requested information about the time format would have been wrong. I've fixed this format and added a test to make sure it stays like this.

#5 Updated by Jean-Philippe Lang over 7 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF