Fix EXT-X-PROGRAM-DATE-TIME in stream

[uvjustin]

Proposed change

The extra #EXT-X-PROGRAM-DATE-TIME tags added to HLS playlists for LL-HLS were incorrect which may have caused issues with some players including Exoplayer. This PR fixes those tags.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[probot-home-assistant]

Hey there @hunterjm, @allenporter, mind taking a look at this pull request as it has been labeled with an integration (stream) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[allenporter]

Apologies, i had a draft review that I forgot to send!

[allenporter]

Feel free to add tests as a follow up.

My streams currently are still displayed with relative zero based timestamps, and not an absolute time fwiw.

[uvjustin]

Feel free to add tests as a follow up.

My streams currently are still displayed with relative zero based timestamps, and not an absolute time fwiw.

This actually led me down a small rabbit hole of revisiting the part boundary behavior and adjusting some minor tests. I will see if I can add them to this PR today.

[uvjustin]

@allenporter I made some updates and force pushed everything, so this needs another look.
I ended up just using the simpler solution of resetting to the adjusted time.
However, this causes a problem regarding the issue with starting timestamps we discussed before. Even though an arbitrary offset won't matter, and you noticed that the offsets always seem to be 0 anyway, we run into problems in the case of discontinuities? We could reset the start_time there, but we would still need to assume that the stream's timestamps get reset to a consistent number which I'm not sure about. The previous method of constantly updating the start_time should avoid this problem.

Edit: I just pushed a commit to reset the start_time in discontinuity(). I'm ok with this - you noted that your cameras reset to 0 and mine seem to reset consistently too. Also this is the current behavior which doesn't seem to be causing any issues.