Scheduled Recordings DST

[toddstar]

Describe the bug
Looks like next recording isn't including DST so after the recent clock change in UK recordings are now listed as an hour earlier than they're actual start time. E.g. my next recording is 10am today but has 9am start time under the scheduled sensor so power automations are firing early.

To Reproduce
Steps to reproduce the behavior:

1. Set Timezone in HA to London (UK)
2. Schedule a recording on Sky
3. (restart to force update or wait for recording data to be updated)
4. Compare scheduled time in HA vs Actual Start time

Expected behavior
Unix Time conversion to include DST adjustment when in use

Screenshots

Component versions

1. v2.10.12
2. not sure

Your configuration
UI

Your configuration from the options dialogue

**    "config_entry_options": {
      "output_programme_image": true,
      "live_tv": true,
      "get_live_record": true,
      "generate_switches_for_channels": true,
      "room": "Living room",
      "advanced_options": true,
      "volume_entity": "media_player.hisense_tv",
      "channel_sources": [
        "BBC Two HD",
        "Channel 5 HD",
        "Dave HD",
        "SkySp PL HD",
        "SkySp F'ball HD",
        "SkySp F1 HD",
        "BBC One HD",
        "Channel 4 HD",
        "ITV1 HD",
        "Sky HistoryHD",
        "SkyHistory2HD",
        "SkySpME UHD"
      ],
      "tv_device_class": true,
      "country": "GBR",
      "epg_cache_len": 30,
      "sources": "{\"TVGuide\": \"tvguide\", \"I\": \"i\"}"
    },**

Additional context

Next Recording Data

        {
            "ast": 1680253078,
            "at": "M",
            "c": "408",
            "canl": true,
            "cn": "SkySp ArenaHD",
            "eg": 7,
            "esg": 13,
            "et": "HD",
            "hd": true,
            "link": true,
            "lto": 3600,
            "oeid": "Ef64-72",
            "osid": "3940",
            "osk": 3940,
            "predictedsz": 10307269,
            "programmeuuid": "48803707-2e67-45e2-98c2-681c01fb56e8",
            "pvrid": "P2907bcc4",
            "s": true,
            "schd": 7200,
            "seriesuuid": "f66f7dae-645f-35fe-a1b3-f2e0f4cea202",
            "slo": true,
            "src": "LIVE",
            "st": 1680253200,
            "status": "RECORDING",
            "sy": "Following an emotionally-charged victory over the Eagles, the Bunnies hop into their next battle against the Storm. The return of Cameron Munster will give Melbourne added impetus. (31.03)",
            "t": "Live NRL: Rabbitohs v Storm",
            "w": true
        },

config_entry-skyq-174343bd318c4652729ac0ee0a62e671.json.txt

[RogerSelwyn]

All times are in UTC. The integration does not know what timezone you are viewing from, so you need to do the conversion yourself. I think there is a ‘to local’ option you can use in any automations. I’m travelling at the moment but I know someone mentioned it on a similar type of post on the O365 integration I look after.

[toddstar]

All times are in UTC. The integration does not know what timezone you are viewing from, so you need to do the conversion yourself. I think there is a ‘to local’ option you can use in any automations. I’m travelling at the moment but I know someone mentioned it on a similar type of post on the O365 integration I look after.

ok cool. Was assuming it was converting from unix to local datetime but if not will look at updating my 'time to next recording' template so that its using local datetime with DST

[RogerSelwyn]

It does a Unix conversion, but Unix is in UTC. 😀

[toddstar]

Had a scan over the code and the issue is that strftime isn't adding the timezone data so that %z format isn't being added to the date stored in HA. i.e. its saving skyq_scheduled_start: '2023-03-31T17:00:00' rather than skyq_scheduled_start: '2023-03-31T17:00:00+00:00' so conversation to local time doesn't work.

I've done a quick and very dirt fix (changed CONST_DATE_FORMAT = "%Y-%m-%dT%H:%M:%S%z" to CONST_DATE_FORMAT = "%Y-%m-%dT%H:%M:%S+00:00") to allow my time to next recording template sensor to be correct. May attempt a proper fix later but probably over my tinkering skills

[RogerSelwyn]

Ok, I’ll take a look at it over the weekend.

[RogerSelwyn]

Latest release (currently in prerelease) should output in timezone (UTC) aware format - https://github.com/RogerSelwyn/Home_Assistant_SkyQ_MediaPlayer/releases/tag/v2.10.13

[toddstar]

Just updated and now outputting with timezone :thumbsup: