View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
04765User patchesSurvey designpublic2010-11-26 18:212012-06-21 13:22
Assigned Toc_schmitz 
Product Version1.90 
Target VersionFixed in Version2.00 
Summary04765: New "datetime" question type
DescriptionAs discussed here: [^]

I've implemented a new question type, "datetime" (type '/' internally), which works like the 'date' question type, but allows an user-specified date format. The date format can contain YmdHi specifiers, allowing to be used also a time question type or any partial date (like my original requirement of a year-month only date).

Dates can be entered both textually and with selection boxes, exactly like 'date'. The selection boxes are built automatically by parsing the date format.

There's also a new question attribute, "datetime_minutes_step", which allows to present the minutes part in controllable steps (usually in 10 or 15 minutes).

Internally the date is stored as a string, but since it's always formatted according to the date format it's easily parseable.

The default time format, if not specified, is taken from the survey's default date format.
TagsNo tags attached.
Complete LimeSurvey version number (& build)9535
Attached Filespatch file icon datetime.patch [^] (43,384 bytes) 2011-02-04 16:01 [Show Content]
? file icon limesurvey_survey_59376.lss [^] (30,095 bytes) 2011-02-04 16:02

- Relationships

-  Notes
c_schmitz (administrator)
2010-11-27 19:52

Hi Yuri,

why did you create a separate question type for that. Wouldn't it be better to extend the existin date question type?
2010-11-29 13:33

Cut&pasting our conversation here for reference:

Am 29.11.2010 11:14, schrieb Yuri D'Elia:
> On Mon, 29 Nov 2010 11:06:19 +0100
> Carsten Schmitz<> wrote:
>> Hello Yuri,
>> year/month date can still be stored, the day would just point to the 1st
>> of the month and tim set to midnight, same for the other examples.
>> The information which of the stored bits is lastly used, can be
>> retrieved from the question configuration.
>> That way a survey admin could even change the format during a survey
>> without messing everything up.
>> And it would still be more easily evaluatable in statistics.
> Basically, you'd suggest to use the format as a mask.
> I didn't think of that, but I will try to extend the 'date' type (I cloned the 'date' code anyway).
That would be great.
> Instead of using the fixed time format array I wrote a couple of functions that translate a phpdate to jsdate/etc. There are some heavy changes to the javascript at runtime, but I think that's feasible. As long as I use the default survey's time format, it should be backward compatible.
Have a look at the existing date converter function - it is pretty
powerful. I'd guess it is all you need. (except for time combinations)

> Does that sound better?
> I have no clue however about what it means for the statistics part, since the format will have to be taken into account differently.

Yeah, I guess to be fast on the evaluation part we will have to use DB
type specific date handling routines if necessary.

Best regards from Hamburg/Germany

Carsten Schmitz
2011-02-04 16:24

I've finished the revised implementation of the 'DATE' question type.

As discussed with Carsten, instead of adding a new question type I added a new
question attribute to the 'D' (Date) question type: date_format.

As the name implies, date_format is a user-customizable date format entered
with the existing "dateformat" specifiers (y/yy d/dd m/mm H/HH M/MM). If a date
format is not specified for a question, it is taken from the survey default.

Internally, the date is now kept as a 'Y-m-d H:i:s' timestamp. When posted, the
date is validated according to the question format, then converted to a
timestamp. When presented, the answer is formatted again with the user supplied
format. When a survey is active, the question column is now a timestamp instead
of a date. This is completely transparent and (according to my tests) also
retrocompatibile with old activated surveys.

For a date field, the popup date picker is only show if the date contains the
day/month/years parts. If a date is partial (containing only hours/minutes, for
example), the date picker is not shown. The accepted characters work according
to the format too.

When dropdown boxes are enabled, the boxes are constructed dynamically with the
specified format, in the same order as the format.

Dropdown dates also have two new attributes: dropdown_dates_minute_step and

minute_step allows to display minutes with the specified time increment (so you
can have 5/10/15 minutes increment instead of displaying a full list of 60

Month_style allows full month names or abbreviated month names to be shown.

I've also modified the code for the dataentry screen. The result here is
suboptimal, since for non-standard date specifiers, the popup calendar cannot
be shown, and the date format is not visible as a hint to the user. Here a
little text showing the format of the date would help. Note that however, for
standard date formats the popup calendar is shown as before, so existing
behavior is *unchanged*.

I've fixed the export for csv/excel/word formats. Here the timestamp is
formatted according to the date format.

The export for spss and R however will show a full timestamp. I think that's
acceptable as a starting point, but I don't have enough knowledge for those
formats to fix it.

I've attached a sample survey to test the various format types and screens.

The patch was done against limesurvey (stable from SVN, version 09740), but it
applies cleanly also to limesurvey_dev.

I've also renamed the "Date" description to "Date/time" in the question-type
dropdown, since I often used this question type to store minutes, months,
hours:minutes and several combinations.

I think that's very flexible.
2011-03-20 12:51

I also successfully ported this patch to the stable branch (currenctly limesurvey#r9891. Please let me know if you are interested for the next RC.
c_schmitz (administrator)
2011-03-28 02:31

wavexx, thank you but it way too late now to get this into 1.91. It will definately go into 1.92.
c_schmitz (administrator)
2011-04-17 16:28

Wavexx, can you please commtt this patch to the _dev branch at [^]
2011-04-20 13:00

Ok, committed into 10017.
The previously attached survey should be a good test.

- Issue History
Date Modified Username Field Change
2010-11-26 18:21 user9586 New Issue
2010-11-27 19:52 c_schmitz Note Added: 13632
2010-11-29 13:33 user9586 Note Added: 13664
2010-12-11 14:00 c_schmitz Assigned To => user9586
2010-12-11 14:00 c_schmitz Status new => feedback
2011-02-04 16:01 user9586 File Added: datetime.patch
2011-02-04 16:02 user9586 File Added: limesurvey_survey_59376.lss
2011-02-04 16:24 user9586 Note Added: 14052
2011-02-04 16:24 user9586 Status feedback => assigned
2011-02-04 16:25 user9586 Assigned To user9586 => c_schmitz
2011-03-20 12:51 user9586 Note Added: 14475
2011-03-28 02:31 c_schmitz Note Added: 14582
2011-04-17 16:28 c_schmitz Note Added: 14837
2011-04-17 16:28 c_schmitz Assigned To c_schmitz => user9586
2011-04-20 13:00 user9586 Note Added: 14851
2011-04-20 13:01 user9586 Assigned To user9586 => c_schmitz
2011-05-07 11:59 c_schmitz Status assigned => resolved
2011-05-07 11:59 c_schmitz Fixed in Version => 2.00
2011-05-07 11:59 c_schmitz Resolution open => fixed
2012-06-21 13:22 c_schmitz Status resolved => closed

Copyright © 2000 - 2016 MantisBT Team
Powered by Mantis Bugtracker