Lisias

Hi, @tw4l . I updated https://github.com/webrecorder/pywb/pull/914 WARCIO is now on version 1.7.5 where the option to get tz aware `datetime`s from the `warcio.timeutils` are implemented. I code reviewed my pull...

Done. All my processes were rebooted using WARCIO 1.7.5 and PYWB with the patches from this [pull request](https://github.com/webrecorder/pywb/pull/914) applied. Everything still work as intended.

I made a mistake, forgot that WARCIO is also using naive datetimes. I'm working on a short term solution, please wait.

I finally got my stuff together and remembered this one. I just realized that WARCIO was updated: https://github.com/webrecorder/warcio/pull/185 (yeah, I'm a bit slow... 😬 ) I'm revising this code and...

That's the history: With WARCIO 1.7.5 giving us the option for getting non naive `datetime`s from it, after this pull request is applied we would have internally code using both...

> `datetime.datetime.now(tzinfo = datetime.tzinfo.UTC)` which should be OK (to be checked). Nope, it will trigger exceptions while doing math with `deltatime` for code that was relying on the previous (current)...

> Apologies, None needed. Don't worry about. > [This post](https://github.com/KSPModdingLibs/KSPCommunityFixes/pull/63#issuecomment-1186469129) suggests it's a known issue with KSPCF. Not sure there's more to add, unless you want to try to detect...

Not every occurrence of `:FOR[foo]:NEEDS[foo]` is going to cause damage. I had an idea to prevent them from being flagged as problems, what would surely cause some friction. I'm testing...

Agreed. This was intended to be published on 0.4.0.4, https://github.com/net-lisias-ksp/KSP-Recall/commit/8389132e21a53abd42aa5575ba790a1c266d54f5 but something changed on 1.12.x that triggered a misbehaviour on the PAW entries. I don't remember right now if it...

This issue is blocked by #78 (forgot to create a `BLOCKED` tag. using `WAITING` for now).