[batelcho]

Oh, and I forgot to ask about two also important things.
The provider is using two URL types:

one is for realtime play with timeshift support for the day and looks like : "https://tvprovider.com/TV/index.m3u8?seek=20201202180000-&" ...... etc.
and the other is for tv archive and looks like: "https://tvprovider.com/VOD/index.m3u8?seek=20201202180000-20201202190000&" ...... etc.

I intentionally don't post real URLs or mention the providers name, because it wants us to use either the website or android app, and for that reason I dumped the URLs from the website (they are requested by another type of URL which expires and responds with aforementioned two types of URLs. This response contains the timestamps I'm having trouble with + another encrypted type of info which bonds those URLs to the IP which makes the request and they doesn't expire after - I'm watching them for over a year now)

So ... my first question is - because realtime play also demands "seek" parameter is it too much to ask for support for "Catchup format specifiers" to work with the main TV stream URL, I think in future maybe some other users will find usage with it also
btw for now the main realtime TV stream URL works with older timestamps playing the TV in real time, but if the provider do a little analysis of the requests, I may find myself in a really sad situation

The other question is related to daylight savings time change - because both types of returned URLs works with GMT timestamps and then the embedded player of the provider use an offset given in the first URL(which expires after) and calculate the right timestamp for its player. Now I'm using "catchup-correction" but after DST change my provider changes the time offset and I need to change "catchup-correction" in M3U file also, which is not hard, but maybe more elegant way can be used for such case.

Thank you, one more time
Any suggestions and ideas are much appreciated

Little correction(because I can't edit my posts yet ) -  I wrote - "Now I'm using catchup-correction .... " earlier, BUT  I'm not using "catchup-correction"  because I cannot use catchup at all without solving the "end time" timestamp syntax problem I have from my first post, but this is my finding about DST