refactor(RSSHandlerRoutine): switch to Instant

[christolis]

From a recent conversation:

[13:09]Zabuzard: while at it, ZonedDateTime should be replaced by Instant in that file
[13:10]Zabuzard: does someone want to tackle that quickly or else we need to make a github issue 🙂
[13:56]christolis: what makes this change worthwhile?
[14:01]Zabuzard: its just the wrong class for the job
[14:01]Zabuzard: there is no reason to use ZDT in this case
[14:01]Zabuzard: Instant is the correct class
[14:02]Zabuzard: shouldnt require any deeper changes in this case, just a quick replacement should work```

[tj-wazei]

Looks reasonable to me.

[ankitsmt211]

this will throw java.time.format.DateTimeParseException, we should handle it instead of just silenty eating the exception. Something like

catch (DateTimeParseException ignored) {
        try {
            //TODO: Should be removed once we cycle through all stored ZDT string instances
            Instant parsed_instant = ZonedDateTime.parse(raw).toInstant();
            //INFO log here converted from raw -> instant
            // save parsed_instant to database so this doesnt trigger exception on next run
            return Optional.of(parsed_instant); //
        } catch (DateTimeParseException e) {
            return Optional.empty();
        }
    }
    

[ankitsmt211]

everything looks good but we should handle the outdated timestamps stored in DB

Dismissing until we figure out a way to migrate the existing data for this to work.

[ankitsmt211]

there's only two ways to handle this atleast the ones i can think of

• one would be the suggestions i made where we handle it direclty by catching those exceptions and updating old type in DB at the same time
• secondly you could disable routine, run a script on server to safely bulk update timestamps to instant merge new code in and enable the routine again

second one has more moving pieces and requires more effort from someone with access to VPS, first one runs and handles things on the fly we can later remove the logic which handles thing on exception once we stop getting the INFO logs for
//INFO log here converted from raw -> instant

[Zabuzard]

btw, having the need to rename this on a type-change indicates that the method name is flawed.

it should be renamed into getTimeFromFormat or more idiomatic parseTime.

Also note the inconsistency with the parameter names called date instead of time. To avoid confusion it should proibably be renamed into parseDateTime and String dateTime, String pattern`

[christolis]

@ankitsmt211 After some testing with the recently pushed changes, I was able to successfully handle outdated date-time strings in the database. No Flyway magic or offline scripts on the VPS needed. A review will be appreciated.

[ankitsmt211]

Here's more context on the discussion around this PR https://discord.com/channels/272761734820003841/895717328359153664/1459639871726420020