View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|07224||Development||Expression Manager||public||2013-01-24 21:26||2021-03-08 20:08|
|Fixed in Version||2.05|
|Summary||07224: EM cannot work with dates (or I cannot work with EM)|
|Description||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).|
But maybe something's wrong with my expression....
|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).
|Additional Information||I tried this as a workaround for the missing time/date validation fields in the time/date question.|
Or am I missing something here?
|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.
year() - gets the year part of the date
month() - gets teh month part
day() - gets the date part
date_add() - to add a specified number of days, months, and/or years
date_diff() - compute the difference between two dates in days, weeks, months, or years.
today() - to get today's date
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:
- Parsing of the date string is necessary only once, when saving a date to the database, not for every small calculation or validation.
- Most of the standard condition or EM logic will work (greater/smaller than, calculation of days between two dates etc.) without implementation of separate functions for handling dates. If you want to have the number of days between two dates then it's just date2-date1. For number of years: (date2-date1)/365. For number of hours (date2-date1)*24 and so on and so forth.
- Standard minimum and maximum fields could be implemented for the date/time questions, which would be parsed, saved and calculated with like described above.
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.
You can also show questions only between certain dates (using relevance equations).
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|
|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|