Feature Request: Date Ranges as Switch Predicates

[BusterNeece]

Liquidsoap can currently do hour, minute, day and "day of the week" as predicates for switches (i.e. to schedule playlists for playback in certain time periods), but it doesn't appear it's currently possible to specify a calendar date range, i.e. to only play a switch while after 2022-01-01 but before 2022-02-01.

This would be very helpful for users who want to schedule their calendars rather far out in advance, and for whom their scheduled entries are often specific to a certain holiday or special event.

[batsonjay]

I'm adding no new requirement to the above; but since I'm the original broadcaster seeking this capability I thought I would provide more background info on this issue. Here's my "user story":

As a station manager I want a particular playlist to play on a specific date at a specific time so that I can arrange in advance for a specific audio file to be played on that specific date-time.

My particular use case: I have pre-recorded "shows" that I want to broadcast on a pre-advertised date/time. Consider the following advertisement we might run on our station: "At 7pm tonight and tomorrow night, the station is going to broadcast a recording of the live show from artist ABC! Tune in for these two nights only!" (The playlist will contain first the station ident, then a (2-hour) recorded file.)

Note that for my use case, the "ending" date is much less important than the ability to assure the playback is kicked off on the scheduled days. (There may be other cases, though, that want more capability; I'm just sharing my need.)

[toots]

Hi all.

The details for this are perhaps specific to each implementation but our responsibility is to provide the tools that are needed to make it possible.

I had a review of the current API and:

• We do have operators to return a parsed version in year/month/day/.. of the current time, in UTC (time.utc) and local time (time.local)
• Ideally, since people nowadays potentially run servers in the cloud with schedules specific to certain time zone, we would like to provide an easy way to return the local time in any timezone. However, the unix/posix API is historically difficult for that so, for now, the solution is to set a global timezone. The mechanism is via the TZ environment variable, which AzuraCast already uses. I have added time.zone.set as a wrapper around this for convenience.
• To round up the API,time.zone has been added and returns a description of the currently set timezone.

All that is good but we were still missing a way to compare local time, so I have added:

• time.make which takes a local time as returned by time.local and time.utc and returns a timestamp in seconds since Jan. 01, 1970 in UTC timezone.

Finally, the API to use with these functions was taken directly from posix and was confusing for non-unix programmers so I changed the method names and value range.

With all this, it should be easy to write predicates such as:

# This is in local time:
def true_on_january_first_2023() =
  start = time.make({
      # Detect DST
      dst  = null(),
      year = 2023,
      month = 1,
      day = 1,
      hour = 0,
      min = 0,
      sec = 0
  })

  stop =  time.make({
      # Detect DST
      dst = null(),
      year = 2023,
      month = 1,
      day = 1,
      hour = 23,
      min = 59,
      sec = 59
  })
  
   current_time = time()
   
   start <= current_time and current_time <= stop
end

[batsonjay]

@toots Thanks for the analysis & additions.

Not being a coder (these days; I was in the past), I'm a BIT fuzzy on where you left this. Are the things above done, merged, and you expect them to be in a minor release? If so, which one (so I can know to get Buster to help me test them)?

[toots]

Hi! The code shown above is currently in the upcoming v2.0.3-preview branch as well as the main branch. It'll come out soon with the 2.0.3 relase.

[batsonjay]

Thank you (both for the new code and the clarification).

Just made a small sponsorship donation as a way of expressing thanks.

[toots]

Thank you!

[gilou]

I missed that discussion, and I like it, I sometimes found myself requiring a restart just to enable a given switch() element for a given date / week, then restart again to turn it off… which is not always welcome… That will help…