Phoenix finish date issue

[rsinha9]

We are seeing Phoenix dates such as "20230418T235959.999999" in the finish and actual finish dates which is failing parsing because the format being used is "yyyyMMdd'T'HHmmss"

[Jon Iles]

Hi @rsinha9 do you have a sample file I can work with? Thanks!

[rsinha9]

@joniles - I'll work on getting you a anonymized PPX file. In the meantime I did a quick test to compare the old converter and the new converter and it looks like the SimpleDateFormat was more lenient compared to the DateTimeFormatter with the LocalDateTime.parse.

    @Test
    public void testParse() throws ParseException {
        String value = "20230214T235959.999999";

        DateFormat df = new SimpleDateFormat("yyyyMMdd'T'HHmmss");
        df.setLenient(false);
        assertThat(df.parse(value)).isNotNull();

        DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyyMMdd'T'HHmmss");
        assertThat(LocalDateTime.parse(value, formatter)).isNotNull();
    }

LocalDateTime.parse actually throws an exception where as the SimpleDateFormat.parse just ignores the .999999

[rsinha9]

Here is a sample file. Both activity 10 and 20 have 235959.999999 as the time and they will come into MPXJ with null values in 12.1.1, and will have the appropriate value in 11.5.4.
23.07.01 - 00 - PHYSICAL PERCENT COMPLETE.ppx.zip

[rsinha9]

Not sure how you want to handle it but I created PR #566 where it falls back to the format with the fractional seconds if it fails to parse with the seconds. We've got other options where we can be more intelligent by seeing if there is a period and then using the fractional format. Let me know your thoughts and I'd be happy to adjust the PR.

[Jon Iles]

Thanks again for the sample file and the PR. I ended up changing the date format to include an optional section which ensures that timestamps with fractional seconds are read correctly. The changes are now in git and will be available in the next release.