Bug: create_iso8601 doesn't consider the rationality of date/time.

[Longfei2]

What happened?

please see the screenshot, `2020-02-60` is not a reasonable date. it should output `2020-02`.

Session Information

No response

Reproducible Example

create_iso8601(c("2020-02-60"), .format = "y-m-d")

[ramiromagno]

Thanks @Longfei2 for your report.

@rammprasad : I am assigning this issue to you as it was your call not to perform semantic validation on parsed components, see

sdtm.oak/tests/testthat/test-iso8601.R

Lines 81 to 87 in 31aadcd

	# No semantic validation is performed on the numeric months, so `"13"` stays
	# `"13"` but representations that can't be represented as two-digit numbers
	# become `NA`.
	expect_identical(
	iso8601_mon(c("13", "99", "100", "-1")),
	c("13", "99", NA, NA)
	)

[botsp]

It seems unlikely for this to happen in real data because most EDC system itself has edit check for data validity. Data like 2020-02-60 cannot input as raw data.

Another case that the uncontrolled character input(UNK, UN, UK...) can occur is when the collection date is partial. The current function seems to have already considered this issue.

[Longfei2]

However, actually, in my company, there are some date issues, e.g. year may be 0000 in system, Feb has 28 or 29 days depends on whether it is a leap year or not. You should cosider these unreasonable dates。

[botsp]

Thanks for the sharing;

But those issues should be addressed by the DM side, not through the SDTM mapping process. Relying on this process to "correct" data can lead to risks of losing traceability and cause inconsistencies between SDTM and EDC collection.

Specifically, 2020-02 is not the expect result in SDTM. Adding a function to the current package to achieve that expectation could bring additional compliance risks.

[Longfei2]

@botsp
Dear author,
Thank you for your answer. In addition to this question, regarding the use of argument ..., I also feel very confused.

In help document, ... is interpreted as "Character vectors of dates, times or date-times' components.". In my view, I can input multiple different vectors as arguments, like this:

sdtm.oak::create_iso8601("2021-02-21", "2022-02", .format = list("y-m-d", "y-m"))

Actually, I expect the output is vector or list like

However, this output is only 2021-02-21.

In my view, if you intend to output a charcter vector, you should only chose single argument, like x or datatime, as your argument instead of ..., otherwise, you should return a list for different vectors input.

Of course, it's possible that I didn't understand your development ideas.

I'm glad to have a discussion with you.

[Longfei2]

Dear,
Sorry to bother you!

I am currently developing an internal package for my company to support SDTM output, so I am very concerned about the status of sdtm.oak and hope that your developed functions can bring some convenience to my work, so I will test some of your functions.

Thank you very much for creating such a great and necessary tool - sdtm.oak.

[Longfei2]

Dear,

regarding partial date issue, there is unexpected output for m-d format input.

According to CDISC SDTM IG - 4.4.2 Date/Time Precision, expected output like:

These partial date issues actually has some solutions in CDISC SDTM IG - 4.4.2 Date/Time Precision.