Add Support for DATE_TIMEs in STATA

[FlipperPA]

When converting a CSV to STATA, I received the following error: src/bin/read_csv/mod_dta.c:404 unsupported variable type 3

This PR adds support for DATE_TIMEs to the STATA writer. Here's the test CSV that was used:

orgpermid,valuecalcdt,justdate
4295533401,2025-03-01 00:00:00,2024-03-01
4295533401,2023-08-26 00:00:00,2024-08-26
4295533401,1974-02-08 00:00:00,2024-02-08
4295533401,1972-06-29 23:59:59.123456+05,2024-02-21
4295533401,1854-03-01 00:00:00,2024-01-01
4295533401,1974-02-08 11:38:23.543212-02,2024-02-08
4295533401,,2024-02-21
4295533401,1972-06-29 23:59:59,2024-02-21
4295533401,1854-03-01 10:42:42,2024-01-01

Here's the JSON mapping file:

{
    "type": "STATA",
    "variables": [
        {
            "type": "NUMERIC",
            "name": "orgpermid",
            "label": "OrgPermID (orgpermid)",
            "format": "UNSPECIFIED"
        },
        {
            "type": "NUMERIC",
            "name": "valuecalcdt",
            "label": "ValueCalcDt (valuecalcdt)",
            "format": "DATE_TIME"
        },
        {
            "type": "NUMERIC",
            "name": "justdate",
            "label": "JustDate (justdate)",
            "format": "DATE"
        }
    ]
}

...and the output in STATA from the written file:

. list

     +-------------------------------------------+
     | orgper~d          valuecalcdt    justdate |
     |-------------------------------------------|
  1. | 4.30e+09   01mar2025 00:00:00   01mar2024 |
  2. | 4.30e+09   26aug2023 00:00:00   26aug2024 |
  3. | 4.30e+09   08feb1974 00:00:00   08feb2024 |
  4. | 4.30e+09   29jun1972 23:59:59   21feb2024 |
  5. | 4.30e+09   01mar1854 00:00:00   01jan2024 |
     |-------------------------------------------|
  6. | 4.30e+09   08feb1974 11:38:23   08feb2024 |
  7. | 4.30e+09                    .   21feb2024 |
  8. | 4.30e+09   29jun1972 23:59:59   21feb2024 |
  9. | 4.30e+09   01mar1854 10:42:42   01jan2024 |
     +-------------------------------------------

...and to validate millisecond display:

. format valuecalcdt %tCHH:MM:SS.sss

. list

     +-------------------------------------+
     | orgper~d    valuecalcdt    justdate |
     |-------------------------------------|
  1. | 4.30e+09   00:00:00.000   01mar2024 |
  2. | 4.30e+09   00:00:00.000   26aug2024 |
  3. | 4.30e+09   00:00:00.000   08feb2024 |
  4. | 4.30e+09   23:59:59.123   21feb2024 |
  5. | 4.30e+09   00:00:00.000   01jan2024 |
     |-------------------------------------|
  6. | 4.30e+09   11:38:23.543   08feb2024 |
  7. | 4.30e+09              .   21feb2024 |
  8. | 4.30e+09   23:59:59.000   21feb2024 |
  9. | 4.30e+09   10:42:42.000   01jan2024 |
     +-------------------------------------+

In reviewing the code, I also noticed the patterns for the three DATE_TIME patterns did not match the Date-Time Unit from the source spec here: https://libguides.library.kent.edu/SPSS/DatesTime

I've also changed those patterns to match the spec.

[evanmiller]

Thanks for the contribution. I left some suggestions.

[evanmiller]

Why was this logic removed?

[FlipperPA]

I had initially copied the value_double_dta to value_double_date_time_dta to ensure code was being reached, before implementing value_double_date_time_dta as its own function. I wasn't sure how this code would handle blank date fields in the CSV.

[evanmiller]

OK, I'm guessing missing ranges are seldom used with dates, so let's leave it out

[FlipperPA]

@evanmiller Thanks for the feedback and suggestions, I'll be the first to admit my C skills are very, very rusty. If there's value in re-inserting the missing_ranges_count, I'm happy to add it back.

[evanmiller]

The macOS build is unhappy for some reason; not sure if related to your change or not

[FlipperPA]

The macOS build is unhappy for some reason; not sure if related to your change or not

@evanmiller Any tips on how I can best figure these out? I've been compiling on Rocky 9 but don't have an easy way to test on MacOS. Thanks again for your guidance and expertise.

[evanmiller]

Looks like a pre-existing error, so I'm not going to sweat it. Thanks for the contribution.