Split from another thread
TLDR or I don't click on links;
You can use Time CONTAINS AM or Time CONTAINS PM, just has to be in uppercase.
You have to use all caps AM or PM, not lowercase am or pm .
The problem comes: what happens if the timezone/locale on the server is set to 24hr time? Does Channels use its internal clock, or rely upon the server's locale?
It gets the current time from the computer it runs on and the airing time from the guide.
Pretty sure it internally uses UNIX epoch time, so it wouldn't matter.
If you look at your schedules json data, all times are UNIX epoch or Zulu (UTC/GMT).
"Time": 1567465200
"Serial": 1567443041
"startTime": "2019-09-02T23:00Z"
"endTime": "2019-09-02T23:30Z"
"UpdatedAt": 1567443041727
If that's the case, do the "AM/PM" qualifiers work on 24hr systems?
Not sure I understand the question?
locale/timezone are just offsets to Zulu/UTC/GMT time.
Per https://www.epochconverter.com/
What is epoch time?
The Unix epoch (or Unix time or POSIX time or Unix timestamp ) is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (in ISO 8601: 1970-01-01T00:00:00Z).
What I mean is:
It seems to imply that internally Channels is using epoch-based time, and adjusting the visual display based upon the system's locale. But if the system's locale is set to something that uses 24hr, then the locale shouldn't know about AM/PM. So by specifying "CONTAINS PM", the time would never match on a system using 24hr locale; to match in a situation like that, you'd need ">=1200", but some comparators aren't available in Channels ...
Not sure what you mean by system's locale is set to something that uses 24hr. That's just a display property for displaying Date/Time, isn't it?
You can do a simple test by creating an advanced pass to specify Channel == somechannel
Then add Time CONTAINS AM or Time CONTAINS PM and look at the results.
I'm sure one of the devs will correct me if I'm wrong, but Channels DVR has to convert the epoch times to local times based on your timezone (not locale, which is not specific enough to derive timezone from) which is an offset from UTC. And I'm sure you're correct that for display purposes such as the schedules and recordings and also for advanced pass Time CONTAINS they convert to a 12hr clock with am or pm indicators.
AM/PM and other Time matchers will require the DVR PC/NAS clock is set to the correct (local) time zone.
1 Like
I guess my problem with this is that time rules for advanced passes are completely inadequate and require creative ways to work around their limitations. Compound rules involving time have limitations.
Until the ability for advanced rules are expanded to properly combine restrictions, they really can't be used beyond recording something like a new Sunday night movie.