Your item will run on a server in one country, for a business in another, with customers in a third. Almost every timezone bug in shipped software comes from storing the wrong thing.
Store in UTC, always
Every timestamp in the database in UTC, without exception. Convert on the way out, for display, using the viewer's timezone. Storing local time means a database whose meaning depends on where the server happened to be when the row was written.
Store the zone, not the offset
"Africa/Lagos" is a zone. "+01:00" is an offset, and offsets change twice a year in much of the world. A booking stored with an offset is wrong for half the year.
Let the owner set theirs
Do not infer the business timezone from the server. A Nigerian shop on a German host is normal, and defaulting to the server means every report is hours out with no visible cause.
The hour that happens twice
Where clocks change, one hour repeats each autumn and one does not exist each spring. If your item schedules anything, decide now what a job set for that missing hour does, because it will happen and doing nothing means it silently never runs.
Dates without times are not timestamps
A birthday or an invoice date has no timezone. Store it as a plain date. Converting it through UTC is how somebody's birthday moves to the previous day for users west of you.
Test with a difficult one
Set your test environment to a zone with a half-hour offset, such as Asia/Kolkata, and one that changes clocks. Bugs that hide under UTC appear immediately.
