View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|07224||Development||Expression Manager||public||2013-01-24 21:26||2014-03-17 22:42|
|Fixed in Version||2.05|
|Summary||07224: EM cannot work with dates (or I cannot work with EM)|
If I check whether a date entered in a date/time question is smaller or larger than a constant date, EM seems to look only at the day in the date (ignoring month and year).
|Steps To Reproduce|
take the attached survey and try different dates.
A text should appear when differnt expressions are true (either date entered is below or above the 12.06.2012).
I tried this as a workaround for the missing time/date validation fields in the time/date question.
|Tags||No tags attached.|
limesurvey_survey_329753.lss (16,668 bytes)
A date is string and compared as a string so
"01.09.2012" is actually smaller/comes before "02.08.2012"
This is not a problem with yy-dd-mm date formats for obvious reasons but if you are using a specific date format you will need to convert it forst for comparison.
Thomas, do you see an easier way? Substr und mktime seems suboptimal here
I recommend standardizing upon a common internal format for date (such as yyyy-mm-dd) and/or datetime and implement a variety of date-specific functions to EM.
Each of those functions would use the internal date representation to do the computation and return a number (except for today(), which would return a string in the format yyyy-mm-dd)
An immediate use case would be to use something like date_diff('y',date_of_birth,today()) to compute someone's age in years.
I'm not a developer...but may I suggest to save dates/times similar to the way they are saved in statsitical software packages or MS Excel: As a number (of days) starting from e.g. 1900/01/01. Hours and minutes are fractions of full days.
I see the following advantages:
I just noticed that many EM/PHP function having to do with handling dates already work with the unix timestamp (number of seconds passed since 1 Jan 1970). So it is easily possible to compare dates, exctract month, day, hour, whatever.
However, all this does not work with dates that are entered/collected using the date question because this question type saves a date as a string. Why not save the date as a unix timestamp to make all this work and life easier? ;-)
TMWhite, I think your suggestion is great. Would you be willing to implement that?
I think mfaber's suggestion of making the internal storage compatible with statistical software is also a good idea; or using the Unix Timestamp.
I'm so busy these days I don't know how long it would take me to get to this.
I totally understand. If this takes time to develop, may I ask/suggest if it's possible to implement the standard EM validation field for this question type. At the moment I do not see a way to validate dates.
With an EM validation field at least comparisons and validation such as
would be possible until a solution is found that allows more user friendly handling of dates/times.
Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=13716
This is basically all resolved-->close
LimeSurvey: master 19241720
Committer: mfaber Details Diff
|Fixed issue 07224: comparison of dates (partial fix)
Dev: LEMval() now returns answers to date questions in yyyy-mm-dd HH:MM
Dev: format, independent of the date format that is chosen for the
Dev: or the particular survey. Thus, comparisons between different date
Dev: questions are possible (e.g. relevance or validation equations
Dev: "arrivaldate > departuredate") even when one question is in
Dev: dd.mm.yy and the other in mm/dd/yyyy HH:MM format
Dev: (same or previous page).
Dev: qanda_helper.php: min/max logic had to be changed accordingly
Dev: and is less complicated now.
|mod - application/helpers/qanda_helper.php||Diff File|
|2013-01-24 21:26||mfaber||New Issue|
|2013-01-24 21:26||mfaber||File Added: limesurvey_survey_329753.lss|
|2013-01-25 11:24||c_schmitz||Note Added: 23801|
|2013-01-25 11:24||c_schmitz||Assigned To||=> TMSWhite|
|2013-01-25 11:24||c_schmitz||Status||new => feedback|
|2013-01-28 18:49||TMSWhite||Note Added: 23850|
|2013-01-28 20:44||mfaber||Note Added: 23854|
|2013-01-28 20:44||mfaber||Status||feedback => assigned|
|2013-02-13 18:05||mfaber||Note Added: 24052|
|2013-02-24 15:00||c_schmitz||Note Added: 24222|
|2013-02-24 15:00||c_schmitz||Status||assigned => feedback|
|2013-02-24 16:37||TMSWhite||Note Added: 24230|
|2013-03-05 11:19||c_schmitz||Project||Bug reports => Development|
|2013-03-06 16:53||mfaber||Note Added: 24568|
|2013-03-06 16:53||mfaber||Status||feedback => assigned|
|2013-08-07 09:29||mfaber||Relationship added||related to 07810|
|2014-01-19 01:23||mfaber||Changeset attached||=> LimeSurvey master 19241720|
|2014-01-19 01:23||mfaber||Note Added: 27999|
|2014-01-19 01:23||mfaber||Assigned To||TMSWhite => mfaber|
|2014-01-19 01:23||mfaber||Resolution||open => fixed|
|2014-03-17 22:42||mfaber||Note Added: 29308|
|2014-03-17 22:42||mfaber||Status||assigned => resolved|
|2014-03-17 22:42||mfaber||Fixed in Version||=> 2.05|
|2014-03-17 22:42||mfaber||Status||resolved => closed|