Select to view content in your preferred language

Time constraint not working

01-29-2018 11:50 AM
Occasional Contributor II

My form contains two time entries (start/end) and I have a constraint to prevent users from entering an end time that occurs prior to the start time. 

This won't work neither in Survey123 Connect or the published form (includes web form).

Any advise will be highly appreciated.

Any advise will be highly appreciat

0 Kudos
3 Replies
by Anonymous User
Not applicable

Hi Javier,

To be able to use the constraint you have used on your survey you need to use dateTime questions, not just Time questions. The reason is because that Time by itself is not relative, therefore 11am can be less than 10am if it is from the day before. If you use dateTime types for your Start and End questions then the constraint will work as expected as the date is taken into account.

Alternatively, there are also default field types of start and end (see the types sheet) which can be used to record the date and time that a survey is started and finished.

If you use dateTime field type or the start and end question types, you can then apply constraints and calculations to these fields as the dates and times are relative to each other.


0 Kudos
Occasional Contributor II

Thanks Phil.

Wouldn’t it make sense though, since Survey123 provides the option to create a time field, to automatically set the day of the epoch EPOCH value to the day the user is selecting the time of interest? There won’t be much value in the date at this point anyway, but probably a much better option. I seems to me that this field would have an important limitation if it doesn’t allow comparing values of the same field type, which is my case.

I understand the workflow around the star/end datetime, but believe these two values are automatically set by the application, so not a whole lot of flexibility here.

My other option is to remove the date field that I created to indicate the date of the burn and rely, as you suggest, on date time fields, although it would be redundant and a little cumbersome for the user, since the date is almost always prior to current, sometimes a few months back.

The good news is that we have a potential workaround.


New Contributor III

I know this is an old post, but I had the same issue and found a solution in the Formulas webpage.
converts a time object to a number representing a fractional day in the device's time zone.
So something like this will work as a constraint if both times are the same day:

decimal-time(${end_time})-decimal-time(${start_time}) >0