Add support for SnakeYaml to be able to parse timestamps correctly when timezone is set or not

[MalloD12]

Impact

• Bug fix (non-breaking change which fixes expected existing functionality)
• Enhancement/New feature (adds functionality without impacting existing logic)
• Breaking change (fix or feature that would cause existing functionality to change)

Description

A new ConstructYamlTimestamp class was created to identify whether a date time should be returned with the timezone included or not.

Fixes #5499

Things to be aware of

• None

Things to worry about

• None

Additional Context

N/A

[StevenMassaro]

Can you point out what part of this class is different from the class it is extending?

[MalloD12]

Sure, the updated/added parts from the original code are these two if blocks:

if (timezoneh_s != null) {
                String time = timezonem_s != null ? ":" + timezonem_s : "00";
                timeZone = TimeZone.getTimeZone("GMT" + timezoneh_s + time);
                calendar = Calendar.getInstance(timeZone);
                ;
            } else {
                calendar = Calendar.getInstance();
            }

and

 if (timeZone == null) {
                return new java.text.SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(calendar.getTime());
            } else {
                return calendar.getTime();
            }

[StevenMassaro]

Is this a change that would be beneficial to make to SnakeYaml itself? I think that if possible, that would be more preferable. I am concerned that as the SnakeYaml class we're extending changes, we won't get the changes ourselves because we override so much of that class.

[MalloD12]

Steve, do you mean we should create an issue or request the SnakeYaml team to make this change we have done here? I think it's true if they make any sort of change to the ConstructYamlTimestamp we won't get it as we override it, although I'm not sure if that could be any time soon. If you guys agree I can create an issue for this change on their end, but let's move ahead with this change and once they fix it on their end we can revert this change. How does it sound to you?

cc: @filipelautert

[StevenMassaro]

Sounds reasonable. I was suggesting that we make a PR on their repo, not an issue, since we know what the change should be.

[MalloD12]

I am not able to create a PR on their repo, but I created this issue for them with the proposed changes we added in this PR. In the meantime, as mentioned above I think we can move forward with this PR and revert these changes once they apply the fix for it (if they do).

Thanks,
Daniel.

[StevenMassaro]

Thanks Daniel!!

[MalloD12]

Hey @filipelautert,

This is pretty much all snakeyaml code. I don't think it's worth spending time on it, since we are going to revert/update this code soon (when they get their code updated).

Thanks,
Daniel.

[rberezen]

Test failure is expected and will be fixed after sync with master. Tested manually, LGTM