How is Time Calculated and Stored in Programming?

@ Technical Discussion

Introduction

I’ve always been kind of bad with dates and time in programming. Usually just rely on handy libraries like dayjs🔗 to handle conversions for me. Honestly, I never really understood what’s going on under the hood—I just know that time is relative, and it’s probably stored in some standard format.

In this article, I want to clear up the basics you actually need to know when dealing with time in programming.

There Are Many Traps with Time

Considering time more carefully reveals that it is something that seems simple but is actually complex:

  • Time is contextual (time zones, various awkward regional time rules)
  • There are different formats for storing time (various format)
  • There are different formatting habits for displaying time

The Concept of Time Zones

The Earth rotates approximately every 24 hours, but the moment of “noon” differs by longitude. To avoid strange things like “having lunch at 3 AM,” time zones ensure that “the sun being at its highest point is roughly equal to noon” is generally true in every region.

Different regions may unify time zones for convenience, such as “dividing the entire country into the same time zone” or “aligning with a political or economic circle,” even if they may differ by several hours. Representation may involve adding or subtracting hours according to a standard: UTC+8, GMT-2.

Daylight Saving Time (DST)

A temporary change in time zone, moving the clock forward by 1 hour in summer. Summer has longer days and shorter nights, allowing for more natural light resources by adjusting the time to encourage early sleeping and waking.

How Do Computers Calculate Time?

Most systems use Unix Timestamp, continuing to this day:

  • UTC Coordinated Universal Time: A time standard not related to time zones, measured by atomic clocks.
  • Unix Timestamp: The number of seconds since 1970-01-01 00:00:00 UTC. Milliseconds, microseconds, and nanoseconds are extensions made by various languages for practical needs.
JavaScript
Date.now() // 1765893674273
Go
time.Now().Unix()      // seconds
time.Now().UnixMilli() // milliseconds
time.Now().UnixMicro() // microseconds
time.Now().UnixNano()  // nanoseconds

How to Store Time?

In summary, time should be divided into two concepts: “moment” and “time zone.” The method of storing time should be chosen based on the nature of its use: “time that should not change meaning with time zone” and “time that will change meaning with time zone.”

  • Does not change meaning with time zone: Publication time
    • It would be strange if changing database Timezone settings or time zone rules would alter the publication time.
  • Changes meaning with time zone: Meeting time
    • Imagine that “meet every Monday at 9 AM.” If we initially store it as a specific UTC time, when daylight saving time switches, the meeting time would automatically change to 10 AM or 8 AM, but the agreement has never changed.

For events that have already occurred, UTC is a fact; for schedules that have yet to happen, Local Time is a fact. Below is a common reference for date storage in databases:

DBTypeStores UTCAuto Converts Time Zone
MySQLTIMESTAMP✅✅
MySQLDATETIME❌❌
PostgreSQLTIMESTAMPTZ✅✅
PostgreSQLTIMESTAMP❌❌
MongoDBDate✅❌

ISO 8601 Time Format

YYYY-MM-DDTHH:mm:ss
  • Z: UTC
  • +08:00: Time zone offset

Why is UTC + Offset Not Enough? What is IANA?

ISO 8601 solves “how to write time,“ IANA (Internet Assigned Numbers Authority) solves “what time is it in that place.”

Because ISO 8601 can only indicate “the difference from UTC at that moment,” yet cannot describe:

  • Does this location with +08:00 observe daylight saving time?
  • Will the rules change in 2026?
  • Has another offset been used historically in some year?

Therefore, in scheduling or future events, IANA should be included:

2025-12-17T09:23:45+08:00[Asia/Taipei]

Further Reading