Fix alarms firing in server timezone instead of player timezone

[boudekerk]

When a player in a different timezone to the server sets an alarm, the alarm would fire at the correct time according to the server's local clock rather than the player's. For example, a player in America/New_York connected to a server in Europe/Amsterdam would have a 7:00 AM alarm fire at 1:00 AM local time.

The fix stores an optional Olson timezone name (_timezone) with each alarm. When present, findNextTime() uses that timezone for scheduling instead of the server's localtime(). Backward compatibility is preserved: alarms without a timezone continue to use server local time unchanged.

On the server side, the Jive alarm menu now includes the player's registered timezone in the alarm add/update action params, so it is sent automatically when the player creates or modifies an alarm via the touch UI.

[boudekerk]

FYI: https://github.com/LMS-Community/slimserver/blob/public/9.2/Slim/Player/Client.pm#L1412

See also: ralph-irving/squeezeos-squeezeplay#28

[michaelherger]

I'm sorry, that's not going to happen. We're not adding 400+ files to solve one person's issue - which likely could be solved using an environment variable.

[boudekerk]

@michaelherger It's still work in progress. But thanks for keeping an eye on it. All comments are appreciated.

[boudekerk]

@michaelherger @mw9 @ralph-irving Can I please pick your brain here?

@michaelherger commented on was trying out using DateTime::TimeZone. That will result in the cleanest code IMO. And, crucially, the Strawberry perl you're using for the Windows installer already includes this dependency anyway.

Including it explicitly in lms, it indeed pulls in 400+ files, although ~300 of those simply contain the timezone data.

I see the following options available (let me know if you see others):

1. Use DateTime::TimeZone (most recently tried approach, works)
   1a. Include it explicitly as a dependency. Works OOTB, everywhere.
   1b. Only include the files we actually use, we can probably trim it down to around ~300-325 files.
   1c. Make it an optional dependency, with a fallback to the server timezone, logging a warning. (Works OOTB on Windows, Linux/MacOS depending on being installed by the sysadmin)
   1d. Only include the dependency for Linux/MacOS (not sure if feasible)
2. Write our own TZ zoneinfo parser
   2a. Include binary zoneinfo files ourselves (~300 files)
   2b. Include binary zoneinfo files only for Windows in slimserver-platforms
   2c. Accept it doesn't work on Windows, simply log a warning and fall back to server timezone.

1b. is my least favourite as it will increase the maintenance burden for little value. Of the ~400 files the DateTime::TimZone dependency introduces ~300 are simply the timezone data. So trimming it down will be marginal anyway and make dependency updates harder. I'd say either we include it as a dependency or we don't, but let me know if you disagree.

My preference is actually 1a. Clean code and a clear dependency. 400 files seems like a lot, but those are included on Windows anyway and 300 of those are simply small timezone data files. Easy to update as well. My second choice would be 1c.

Please let me know which approach you would prefer and I can make the required changes and put it forward for review. Thanks.

P.S. @michaelherger Your suggestion of an env variable, won't actually work on Windows AFAIK. I'm not sure what workaround for this bug there is available there today.

[boudekerk]

Another option is to have 1c with a fallback to 2.
Should work OOTB without any extra files needed on all platforms, but will use different code for both, so not my preference.

[michaelherger]

Another option is to have 1c with a fallback to 2. Should work OOTB without any extra files needed on all platforms, but will use different code for both, so not my preference.

I wanted to suggest this: use DateTime::TimeZone where available (in particular Windows), fall back to POSIX for the others? As you say the former was available on Windows this should be relatively light weight?

if (main::ISWINDOWS) {
...
}

[boudekerk]

@mw9 @ralph-irving Any comments? If not I'll start work next week on the multi-tiered approach as discussed with @michaelherger.

[ralph-irving]

@ralph-irving Any comments? If not I'll start work next week on the multi-tiered approach as discussed.

No I don't really have anything to offer on these changes. I've never used the alarm features of the firmware.
As long as there is agreement that the changes included in a PR are sound for the community firmware I will include it.