Default value for date in 0.3.1

Issue #488 resolved
Thomas Guiot created an issue


I’m not sure if this is a bug or simply a feature implemented specifically like this, but I’m trying to set a default date for the date type, using the same mechanism as for other types.

so in the calculation procedure, i add something like:

import datetime
mydate =, 4, 1)

It doesn’t matter what I put as a date or datetime object, the result is always the same : the actual displayed date in the test itself is 20 Dec 2017. I’ve tried with META['work_started'], and a bunch of other. It’s always 20 Dec 2017. (Why this particular date ??)

Then I tried to get the result of this date field in another composite, and it looks like I received “2017-12-20”. So I tried to provide a string using the same format, like “2020-04-01”, but again only “20 Dec 2017” was displayed.

Last thing I tried was to provide a string using the same displayed format. I tried with “01 Apr 2020”, and it actually worked. The displayed date was indeed 01 Apr 2020, and when I clicked on the calendar, it was set to 01 Apr 2020.

So it looks like the date object is not exactly a true python date object or I’m missing something maybe.

I just tried one last thing : first create an actual date object with d =, 4, 2) then set mydate to d.strftime('%d %b %Y')

So you really need to put a string in this particular format. I assume that there are actually two objects behind this date type : the actual python date object, and its string representation that gets displayed in the box.

There are ways to improve this, imho:

  • allow the users to change the date format to whatever they want, much like they can with numerical types. As long as you use the correct python syntax like ‘%Y-%m-%d’, the displayed text should use the strftime method from datetime objects to display it in the box. This is also helpful for international situations where you don’t want to see “Apr” for April. Or for dicom consistency where every date is in the format %Y%m%d like 20200401
  • when you set a default value, set an actual date or datetime python object rather than a string
  • I also wonder whether it’s really useful to have date and datetime. Whatever you do with a date object, you can also do with a datetime object. The reverse is not true.



Comments (2)

  1. Randle Taylor

    Thanks for these comments Thomas!

    There’s a couple things going on here. In theory, setting the result to a datetime object should work, however when QATrack+/Django serialize the datetime object to a text format (JSON) to send it to the web browser it gets converted to ISO format (i.e. datetime.isoformat()). However, the date/time picker widget on the front end is expecting the %d %b %Y format and so it incorrectly interprets the isoformat resulting in a mangled date. This needs to be fixed by having the QATrack+ JSON encoder serialize datetime objects to use the same format as everywhere else. I added a fix for this here: d3b09796

    When you manually set the date to the correct string format, it is sent directly to the browser like that, so the datepicker widget correctly interprets the format which is why it works.

    With regards to your points:

    • I am working towards making the date formats configurable for an installation (see e.g. but at this point I’m unlikely to make arbitrary formats for datetime tests possible as it requires ensuring the javascript widget knows which format the user is passing the date as. This is probably possible, but not a high priority for me as I think its better to use the same datetime format everywhere on a site (e.g. it should be configured once at installation time, and not on a per test basis). If someone wants to take a crack at implementing that though I would be happy to review it. If you want to use dates of a specific format for a test, you might try just using a string test and then formatting your date explicitly in the calculation procedure.
      As I said though, I hope to make it possible to specify a specific date & datetime format on a site-wide basis to make internationalization better, or to allow using the same date format in QATrack+ as you do elsewhere in your institution.
    • This “works” currently in the sense that you can use a datetime objects but had a bug in the way it’s serialized as discussed above.
    • Having date & datetimes separately was not much of a cost in terms of implementation and it’s a bit more convenient from the end users perspective. If there was only datetime tests and a user just wants to pick a date, then they would also have to choose some arbitrary time in the widget which I don’t think is ideal.

    Thanks again, having people do testing like this and submitting bug reports is extremely useful!

  2. Log in to comment