Update Date formats with `lubridate` for better readability and check of `visit_schedule()` bindings to Datetime variables

[Melkiades]

Motivation

These changes need to be thoroughly checked downstream as a Date object in lubridate may be different from standard as.Date() calls, and therefore it could break some things downstream. An eventual hotfix is to cast the date columns to characters or base-date. Still, I argue that lubridate is a higher standard both for readability and usability. Checking the code for ADEX, I think there could be a bit more organization and more modular calls to dplyr (i.e. less grouping of mutate) so to understand better how the data is gradually expanded and what are the key parameters. This is clear in ADSL but not in other data-set as ADEX.

I think this simplification work could make further modifications of data sets faster and more effective. I used Hmisc::describe() and table(data[, two_cols_I_want_to_compare]) to understand a bit better some columns.

This issue is mainly about date formats and simplifications but follows inconsistency problems caused by the hotfix of visit relative days (see teal.osprey#170, thanks @nikolas-burkoff).

Feel free to refine the issue @ayogasekaram @edelarua.

Todo

Change the following datatime variables to use lubridate class

• [x] random.cdisc.data/inst/metadata/ADAE.yml: ASTDTM:
• [x] random.cdisc.data/inst/metadata/ADAE.yml: AENDTM:
• [x] random.cdisc.data/inst/metadata/ADAE.yml: LDOSEDTM:
• [x] random.cdisc.data/inst/metadata/ADAETTE.yml: ADTM:
• [x] random.cdisc.data/inst/metadata/ADCM.yml: ASTDTM:
• [x] random.cdisc.data/inst/metadata/ADCM.yml: AENDTM:
• [x] random.cdisc.data/inst/metadata/ADEG.yml: ADTM:
• [x] random.cdisc.data/inst/metadata/ADEX.yml: ASTDTM:
• [x] random.cdisc.data/inst/metadata/ADEX.yml: AENDTM:
• [x] random.cdisc.data/inst/metadata/ADHY.yml: ADTM:
• [x] random.cdisc.data/inst/metadata/ADLB.yml: ADTM:
• [x] random.cdisc.data/inst/metadata/ADMH.yml: ASTDTM:
• [x] random.cdisc.data/inst/metadata/ADMH.yml: AENDTM:
• [x] random.cdisc.data/inst/metadata/ADQS.yml: ADTM:
• [x] random.cdisc.data/inst/metadata/ADRS.yml: ADTM:
• [x] random.cdisc.data/inst/metadata/ADSL.yml: TRTSDTM:
• [x] random.cdisc.data/inst/metadata/ADSL.yml: TRTEDTM:
• [x] random.cdisc.data/inst/metadata/ADSL.yml: TRT01SDTM:
• [x] random.cdisc.data/inst/metadata/ADSL.yml: TRT01EDTM:
• [x] random.cdisc.data/inst/metadata/ADSL.yml: TRT02SDTM:
• [x] random.cdisc.data/inst/metadata/ADSL.yml: TRT02EDTM:
• [x] random.cdisc.data/inst/metadata/ADSL.yml: AP01SDTM:
• [x] random.cdisc.data/inst/metadata/ADSL.yml: AP01EDTM:
• [x] random.cdisc.data/inst/metadata/ADSL.yml: AP02SDTM:
• [x] random.cdisc.data/inst/metadata/ADSL.yml: AP02EDTM:
• [x] random.cdisc.data/inst/metadata/ADSUB.yml: ADTM:
• [x] random.cdisc.data/inst/metadata/ADTR.yml: ADTM:
• [x] random.cdisc.data/inst/metadata/ADTTE.yml: ADTM:
• [x] random.cdisc.data/inst/metadata/ADVS.yml: ADTM:

[shajoezhu]

@JiaLiu0001 , fyi, once we make forward with this issue, we should be able to introduce datetime class

[edelarua]

@Melkiades I will start looking into implementing this today. I'll start at adsl and then work my way down the datasets alphabetically so if you start from the bottom of the list alphabetically we won't overlap (depending on how much work this issue requires) if you want to work on this as well. On the bright side, there are less things we'll have to check for breakage since decoupling scda.2022 from tern and teal.modules.clinical!

[shajoezhu]

decoupling scda.2022 from tern and teal.modules.clinical is the best thing happened this year! hahaha