Allow relative days for date and timestamp columns in csv-to-docs command

[binokaryg]

We want to create a set of dummy data for web-app which includes a bunch of reports that should trigger tasks and show targets as soon as we upload them. For this to work, we need a mechanism to calculate the timestamp/date fields in the forms relative to the current date.
Although this has been done in the past by writing relative days in JSON and running through external scripts, there does not seem to be a reliable way of doing it from within medic-conf.
Can we add this feature in medic-conf?

[tookam]

ready for AT 230-csv-to-docs-with-relative-dates

[binokaryg]

When using date_of_birth:rel-date, I get the calculated birth date as 2019-11-08T19:00:41.486Z. Is there a way to get just the date (without time) )in the ISO 8601 format: 2019-11-08?
For the rel-timestamp it could be more useful to be able to supply the time in milliseconds.

[ngaruko]

@wtekeu ^

[tookam]

@binokaryg the branch has been updated with your suggestions.

[binokaryg]

Thanks, @wtekeu, rel-date works great now.
One small consideration for relative timestamps is that, is it possible to make the "current time" fixed for a single batch?
I tried creating 30 persons all with reported_date:rel-timestamp = 100.
In the resulting docs, I got three different but consecutive dates:

1. 1574244658662 (Persons 1-6)
2. 1574244658663 (Persons 7-22)
3. 1574244658664 (Persons 23-30)

I guess the reason for this could be "current time" being read dynamically during the processing of each document. If that's the case, can we just read a "current time" at the beginning and stick to that throughout the batch?

Although it shouldn't create any problem in real life but it can affect automated tests.

[ngaruko]

Thanks @wtekeu and @binokaryg . We can approach these two ways since it is not likely to affect anyone in 'production' : a) work on it now and get it over and done if it is a minor job or b)if it is time-consuming, close the ticket and open a new one when/if it becomes an issue with automated tests.
Since the branch is PR is still active, I would go with option a) but if option b) looks more efficient, feel free to push it back to AT @wtekeu and we will decide whether there is a need for another ticket...

[tookam]

@binokaryg and @ngaruko I opted for a) .. please test latest changes

[binokaryg]

It works like a charm! Thanks.