https://blog.vnaik.com/posts/time.html
Handling time when developing can be tricky. Time calculations depend on imprecise and variable physical features (eg. leap seconds to account for the rotation of the earth) and socio-political features (eg. time zones) and this means there could be several pitfalls between expectation and reality when working with time.
First, an introduction to certain time-related concepts.
UTC provides a uniform framework with which to look at time, abstracted away from the vagaries of local times. Interpreting UTC dates is mostly straightforward; issues only arise when converting UTC to local times. This is less of a problem for dates in the past (unless you look at historic dates, maybe older than a few decades or centuries i.e., before the epoch) and more of a problem for dates in the future.
Flavours of time: UT is a time standard based on the Earth's rotation; and UT1 is conceptually the solar time at 0° longitude but is calculated based on distant quasars because precise measurements of the sun are difficult. It is an accurate reflection (or as close as our technology allows) to the actual rotation of the earth. TAI is a time standard where every day is exactly 86000 seconds long, and is measured as the weighted average of about 400 atomic clocks around the world. GMT is mean solar time and is correlated to UT1, and may differ from UTC by up to 0.9 s. GPS time is TAI offset by 19 seconds and no leap second correction is applied. TAI is a reference timekeeping standard maintained by atomic clocks and is an abstract scale disconnected from physical reality. UT1 is solar time and is correlated to actual physical reality, to the rotation of the Earth which is variable from day to day. UT1 is correlated to reality but is inconvenient and irregular, while TAI is very convenient and regular - and thus UTC is based on TAI, but because TAI can go out of sync with UT1 from time to time, and because we cannot speed up the earth to make UT1 and UTC agree with each other, we instead use leap seconds to ensure UTC and UT1 are always within 0.9 seconds of each other. This means UTC is a discontinuous (because of leap seconds), abstract (because it is not perfectly correlated to the Earth's rotation), and reliable time-scale for almost all programming needs. Leap seconds are added about every year and a half on average.
However Unix time is affected by leap seconds and it handles these by 'replaying' the previous second - thus, each day has 86400 seconds and time goes backwards for a second. UTC does not replay seconds and instead has an extra second on days with a leap second for 86401 seconds. Unix time is measured as the number of seconds since the epoch (January 1 1970 in UTC) and is not affected by time zones or daylight savings. The start of the epoch is very close to the start of modern UTC timekeeping and representing and using precise dates from before this time can be challenging. Luckily that is rarely a problem for most projects.
32 bit Unix time will overflow in 2038 so a 64 bit integer will need to be used to represent times beyond this.
Given the reliability of UTC, the most natural way of handling time when programming is to store times in UTC (either as a time stamp or an ISO-8601 string) and convert to local times applying current time zone rules as needed.
Just about the only thing that can go wrong is the time zone rules changing between when the time was recorded and the time the date is interpreted. In this context, time zone rule changing means that the government in question has either removed or introduced daylight savings time, or moved the country to another time zone altogether. Since time zones are a political definition and not a technological one, such changes can and will happen arbitrarily for reasons that have nothing to do with technology.[1][2][3]
This also applies to dates in the past, because interpreting old dates precisely may require the use of historic time zone rules instead of the current ones. However, this is a very niche problem and by and large current time zone rules will suffice. Thus, our time zone rules (as long as they are up-to-date) tell us how UTC maps to local time right now, but we don't know for sure today how UTC time will map to local time in the future because the time zone rules could change between now and then.
Fortunately, the most common use-case for time is also the easiest - recording times of events, usually as they happen (e.g., when an email is received, when a user logs in, etc.) - these dates are always in the past and are best stored as UTC. They can be converted into local time when read using the latest time zone rules.
Things are a bit more complicated when dealing with dates in the future, for example, to implement a scheduling or reminder system.
On the other hand, if you are interested in a specific universal instant in time in the future then UTC is a good fit. For example, if a task needs to run at 24 hour intervals irrespective of calendar time then use UTC. Future times are usually about human expectations. For example, "10:00 AM next Tuesday" is a human time, not UTC or a Unix time stamp. This future time can be converted to UTC right now for storage, but the converted value could be affected by: