Fix for unexpected zero value last edit dates in segment archiving

[bx80]

Description:

If a segment has a last edited date of 0000-00-00 then segment archiving will fail with the exception: The date ... is a date before first website was online.

This is caused by attempting to parse the invalid 0000-00-00 date string. This PR adds a simple check to avoid parsing if the last edited date is null or zero along with some additional tests to check an exception isn't thrown when zero dates are provided.

ref: L3-522

Review

• Functional review done
• Potential edge cases thought about (behavior of the code with strange input, with strange internal state or possible interactions with other Matomo subsystems)
• Usability review done (is anything maybe unclear or think about anything that would cause people to reach out to support)
• Security review done
• Wording review done
• Code review done
• Tests were added if useful/possible
• Reviewed for breaking changes
• Developer changelog updated if needed
• Documentation added if needed
• Existing documentation updated if needed

[caddoo]

While you are in this private method, I have some suggestions of small improvements, let me know what you think.

• Add type hinting / return type
• The method name doesn't really indicate the full picture of what it's doing, can it be clearer.
• The method is doing two things, would it be worth splitting into two methods?

[bx80]

Add type hinting / return type

Done.

The method name doesn't really indicate the full picture of what it's doing, can it be clearer.

Not really, the method is called getCreatedTimeOfSegment, it gets the created time of the supplied segment and also returns the last edited time, but I don't think renaming it to getCreatedTimeOfSegmentAndLastEditedTimeOfSegment going to be helpful to anyone other than ultrawidescreen monitor manufacturers.

The method is doing two things, would it be worth splitting into two methods?

Unless we're going to try to enforce a 'method can only do one thing' rule and subsequently undertake long term refactoring of all existing code to this standard then I don't see any meaningful benefit in breaking this particular 13 line method into two slightly smaller methods.

let me know what you think.

The style preferences highlighted here could also apply to most of the codebase so I think it would be more efficient and constructive to address them via general project wide coding conventions.