This is bad advice if you need to store future events/appointments. Because in the majority of cases the meaning of the future datetime is "the date/times on th

This is bad advice if you need to store future events/appointments. Because in the majority of cases the meaning of the future datetime is "the date/times on the majority of the calendars and clocks on the wall in the vicinity of the event". The implication is that if the local timezone rules change between now and the future event, the user wants the local datetime of the appointment to stay unchanged, which implies that the UTC/epoch version of the appointment has to be changed. Generating the correct datetimes from UTC/epoch+local timezone requires a lot more administration and logic than storing just the local datetime. (You need at least both the current TZ database and the version when the appointment was made/last changed to have a hope to do this correctly.)