timezone offset in update of current_clip_start_time

[valentina-s]

I am trying to use DateRangeHLSStream and I am puzzled by the update in current_clip_start_time.

    stream = DateRangeHLSStream(stream_base = stream_base,
    polling_interval = 30,
    start_unix_time = test_humpback_time - 60,
    end_unix_time = test_humpback_time,
    wav_dir = './',
    overwrite_output=True,
    real_time=False)

    stream.get_next_clip()

Before running stream.get_next_clip(), stream.current_clip_start_time is 2020-01-08 02:06:00, while after that, it is 2020-01-08 10:06:30, so there is an offset of 8 hours plus the expected 30 sec. The update is through the add_interval_to_unix_time function. Why is the timezone needed here if working with unix timestamps?

[EveningShower]

I tried looking into this, and it seems that the function add_interval_to_unix_time converts the unix timestamp to an aware datetime instance that's based on the pacific time timezone, that's why it gives an offset of 8 hours in your case.

So I looked into all the uses of the add_interval_to_unix_time function to try to see why it does that but there doesn't seem to be any reason for it, as it's only used in the get_next_clip() function.

I suggest removing the line self.current_clip_start_time = datetime_utils.add_interval_to_unix_time(self.current_clip_start_time, self.polling_interval_in_seconds) in DateRangeHLSStream.py and replacing it simply with self.current_clip_start_time = self.current_clip_start_time + self.polling_interval_in_seconds as it solves the problem.