|Anonymous | Login||2014-12-20 01:54 CET|
|My View | View Issues | Change Log | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|04765||User patches||Survey design||public||2010-11-26 18:21||2012-06-21 13:22|
|Target Version||Fixed in Version||2.00|
|Summary||04765: New "datetime" question type|
|Description||As discussed here: http://sourceforge.net/mailarchive/forum.php?thread_name=20100910163018.da050f0b.yuri.delia%40eurac.edu&forum_name=limesurvey-developers [^]|
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.
|Tags||No tags attached.|
|LimeSurvey build number OR git commit ID||9535|
|Attached Files|| datetime.patch [^] (43,384 bytes) 2011-02-04 16:01 [Show Content]
limesurvey_survey_59376.lss [^] (30,095 bytes) 2011-02-04 16:02
why did you create a separate question type for that. Wouldn't it be better to extend the existin date question type?
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<firstname.lastname@example.org> 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.
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
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 #9740), 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.
|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.|
|wavexx, thank you but it way too late now to get this into 1.91. It will definately go into 1.92.|
Wavexx, can you please commtt this patch to the _dev branch at
Ok, committed into #10017.
The previously attached survey should be a good test.
|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 - 2014 MantisBT Team|