msandin's comments

Indeed, but this is representative of a very real change in the relationship between your clocks. The only way to keep this non-surprising is to make the time zone the schedule runs in explicit to the user. If somebody in a different zone edits the schedule it has to remain in the original time zone unless they explicitly change it. You do all your scheduling calculations in the schedule time zone and then convert it to an instant in time, likely expressed as a UTC time, when you need to calculate how long your computer should wait until the next event.

(Date)Times stored in the schedule (start times, end times, trigger times, clock times) are not instants in UTC, they are time specification in a calendar system which can only be interpreted as specific instants in the context of a particular time zone. Which is stored explicitly and separately from the calendar date-times.

This crucial separation of a time specifications in a calendar system from instants in time is one thing which many date/time libraries get wrong and which Noda-/JodaTime gets right.

Unless you do recurrent scheduling. In that case it's important to understand that you schedule in a particular timezone. Both because the relationship between local time an UTC changes throughout the year with DST changes and because evaluating an expression like "Thursdays at 03:00" might evaluate differently if you first move the time to UTC (say 22:00) and then check if it's a Thursday (no, it's only Wednesday still, but in 24 hours it'll be time).

Not very it would seem given that "pipa" does not mean "pipe" in the sense TPB are using it but rather only in the sense of a "pipe for smoking". A pipe in the sense TPB use it would be "rör". But relating the combination "trash" and "pipe for smoking" to their line of reasoning seems at least a little harder/more far fetched.