Unix Timestamp: ano ito, conversion at pag-imbak sa mobile development

Ano ang Unix Timestamp?

Unix Timestamp (kilala rin bilang POSIX time, Epoch time o Unix time) — ay isang sistema ng pagsukat ng oras na tumutukoy sa bilang ng mga segundo na lumipas mula Enero 1, 1970 00:00:00 UTC (panahon ng Unix). Ang petsang ito ay pinili bilang simula ng pagbilang para sa operating system na Unix, at kalaunan ang format ay naging de facto standard para sa representasyon ng oras sa mga computer system. Hindi isinasaalang-alang ng Timestamp ang mga leap second — bawat minuto ay binibilang bilang 60 segundo, kahit na ang International Earth Rotation Service ay minsan nagdaragdag ng karagdagang segundo para itama ang atomic time.

Panahon ng Unix: bakit 1970?

Ang pagpili ng Enero 1, 1970 ay nauugnay sa kasaysayan ng pag-unlad ng operating system na Unix. Pinili ng mga developer na sina Ken Thompson at Dennis Ritchie ang petsang ito bilang isang simple at bilog na panimulang punto — ito ay sapat na maaga upang masakop ang lahat ng posibleng petsa, at sa parehong oras ay sapat na huli upang ang oras ay maiimbak sa isang 32-bit signed integer. Sa una, ang oras ay sinusukat sa ikaanimnapung bahagi ng segundo, pagkatapos ay sa ticks (1/60 segundo), at sa ikapitong edisyon lamang ng Unix (V7, 1979) ang format ay nagpapatatag bilang isang buong bilang ng mga segundo. Ayon sa The Open Group Base Specifications (Issue 8, 2024), ang mga sistemang compatible sa POSIX ay kinakailangang suportahan ang format na ito.

Paano Gumagana ang Unix Timestamp

Ang prinsipyo ng pagtatrabaho ng Unix Timestamp ay batay sa isang simpleng counter: bawat lumipas na araw ay nagdaragdag ng 86 400 segundo sa halaga. Halimbawa, ang timestamp 1 720 000 000 ay tumutugma sa isang petsa sa kalagitnaan ng 2024 — ang eksaktong conversion ay maaaring gawin sa pamamagitan ng paghahati sa bilang ng mga segundo sa isang araw, oras, at minuto. Ang ganitong approach ay ginagawang ideal ang timestamp para sa machine storage: ito ay isang integer na sumasakop ng 4 bytes (32-bit int) o 8 bytes (64-bit long) at sumusuporta sa direktang paghahambing — mas malaking timestamp = mas huling petsa.

Matematika ng Conversion

Isang araw = 86 400 segundo (24 x 60 x 60). Isang oras = 3600 segundo. Upang i-convert ang timestamp sa petsa, kailangan mong sunod-sunod na kalkulahin ang bilang ng mga araw, oras, minuto, at segundo mula sa simula ng panahon. Baliktad na conversion — i-convert ang petsa sa mga araw mula 1970-01-01, pagkatapos ay i-multiply sa 86 400 at idagdag ang offset mula sa UTC. Sa Java at Kotlin, ang mga kalkulasyong ito ay naipatupad na sa mga standard na klase na java.time.Instant at java.util.Date, na nagpapalaya sa developer mula sa manu-manong pagkalkula.

        // Kunin ang Unix Timestamp sa segundo
val seconds = System.currentTimeMillis() / 1000

// I-convert ang timestamp sa petsa sa pamamagitan ng java.time
val instant = Instant.ofEpochSecond(seconds)
val localDate = instant.atZone(ZoneId.of("Europe/Moscow")).toLocalDate()

// Baliktad: petsa sa timestamp
val date = LocalDate.of(2026, 7, 21)
val ts = date.atStartOfDay(ZoneOffset.UTC).toEpochSecond()

Conversion ng Unix Timestamp sa Petsa at Bumalik

Ang conversion ng Unix Timestamp sa petsa na nababasa ng tao ay isa sa mga pinakakaraniwang operasyon sa mobile development. Sa Android, ilang paraan ng conversion ang available depende sa minimum na bersyon ng API: para sa API 26+ inirerekomenda ang java.time.Instant, para sa mas lumang bersyon ay ginagamit ang java.util.Date at java.text.SimpleDateFormat. Mahalagang tandaan na ang Android at JVM ay default na gumagamit ng milisegundo, hindi segundo — kung ang timestamp ay natanggap mula sa server sa segundo, dapat itong i-multiply sa 1000 bago ipasa sa mga standard constructor.

Conversion na may Time Zone ng User

Isa sa mga pangunahing bentahe ng Unix Timestamp ay ang kalayaan nito mula sa lokasyon. Ang server ay palaging nagbabalik ng timestamp sa UTC, at ang conversion sa lokal na petsa at oras ay ginagawa sa panig ng client. Sa Kotlin, para dito ginagamit ang ZonedDateTime na may angkop na ZoneId — system o pinili ng user. Kung ang application ay nagpapakita ng oras sa iba’t ibang zone (halimbawa, para sa mga manlalakbay), inaalis ng timestamp ang pangangailangan na magpadala ng time zone mula sa server — isang time stamp ay sapat na.

// Conversion na may time zone ng user
fun formatTimestamp(seconds: Long, zoneId: ZoneId): String {
    val instant = Instant.ofEpochSecond(seconds)
    val formatter = DateTimeFormatter
        .ofPattern("dd.MM.yyyy HH:mm:ss")
    return formatter.format(instant.atZone(zoneId))
}

// Halimbawa: timestamp = 1720000000, zone = Europe/Moscow
val result = formatTimestamp(1720000000, ZoneId.of("Europe/Moscow"))

Problema ng Taong 2038

Problema ng Taong 2038 (Year 2038 Problem, Y2K38) — ay isang pangunahing limitasyon ng 32-bit signed integer para sa pag-iimbak ng Unix Timestamp. Ang maximum na halaga ng 32-bit signed int ay 2 147 483 647, na tumutugma sa Enero 19, 2038 sa 03:14:07 UTC. Pagkatapos ng petsang ito, ang halaga ay umaapaw at nagiging negatibong numero, na nagdudulot ng mga pagkasira sa mga system na gumagamit ng 32-bit time_t. Ang problema ay katulad ng kilalang Y2K, ngunit pangunahing nakakaapekto sa mga embedded system, lumang bersyon ng Android, at mga IoT device na may 32-bit architecture.

Saklaw ng Problema

Ayon sa Linux Foundation (2025), humigit-kumulang 15% ng mga Linux device sa industrial at IoT segment ay gumagamit pa rin ng 32-bit compilations. Para sa mga Android device, ang panganib ay mas mababa — karamihan sa mga modernong smartphone ay tumatakbo sa 64-bit processors (ARM64), ngunit ang mga lumang modelo na may Android 4.x at mas mababa ay maaaring gumamit ng 32-bit time_t. Ang solusyon sa problema — paglipat sa 64-bit time_t, na ligtas sa loob ng 292 bilyong taon. Simula sa Android 5.0 (API 21), lahat ng device ay gumagamit ng 64-bit na oras sa kernel level. Ang mga developer ng mobile application ay sapat na mag-imbak ng timestamp sa Long (64-bit) type upang maiwasan ang problema sa application level.

Paggawa gamit ang Unix Timestamp sa Android

Sa Android development, ang tamang pagtatrabaho sa Unix Timestamp ay kritikal para sa pag-sync ng data, pagpapakita ng oras ng pagtanggap ng mensahe, pagkalkula ng mga timeout, at pag-iskedyul ng mga notification. Ang system call na System.currentTimeMillis() ay nagbabalik ng kasalukuyang oras sa milisegundo mula sa panahon ng Unix — ito ang pinaka-tumpak na source ng oras na available sa device. Para sa mga network request, karaniwang ginagamit ang Unix Timestamp sa segundo, dahil ang karamihan sa mga REST API at database ay eksaktong gumagana sa segundo.

Mga Inirerekomendang Practice

Huwag kailanman gamitin ang System.currentTimeMillis() para sa pagsukat ng mga interval — para dito mayroong System.nanoTime(), na monotonic at hindi nakadepende sa mga pagbabago ng orasan ng user. Para sa pagpapakita ng oras, palaging i-imbak ang timestamp sa UTC at i-convert sa lokal na time zone sa panig ng interface. Sa pagtatrabaho sa mga database (SQLite, Room), gamitin ang INTEGER type at i-imbak ang timestamp sa segundo — ito ay sumasakop ng 8 bytes (Long) at sumusuporta sa native SQL sorting. Para sa serialization sa JSON, inirerekomenda na ipadala ang timestamp bilang numero (Long), hindi bilang string — ito ay mas compact at mas mabilis i-parse.

// Tamang pagsukat ng oras ng execution
val start = System.nanoTime()
// ... operasyon ...
val elapsed = System.nanoTime() - start
val seconds = elapsed / 1_000_000_000.0

// Mag-imbak sa Room (Entity)
@Entity
data class Message(
    @PrimaryKey val id: Long,
    val text: String,
    val createdAt: Long // Unix Timestamp sa segundo
)

Paghawak ng Oras mula sa Server

Kapag tumatanggap ng Unix Timestamp mula sa server, palaging suriin ang unit ng pagsukat: ang ilang API ay nagbabalik ng milisegundo (compatible sa JavaScript), ang iba naman — segundo (POSIX standard). Ang kasunduan tungkol sa mga unit ay dapat naitala sa dokumentasyon ng API. Sa tugon ng server, ang timestamp ay maaaring ipadala bilang Long (JSON number) o String (ISO 8601). Para sa debugging, magdagdag ng utility function na nagpapakita ng timestamp sa format na nababasa ng tao — pinapadali nito ang pagsusuri ng kawastuhan ng mga time stamp sa panahon ng development.

Pag-iimbak ng mga Time Stamp sa Database

Ang pagpili ng format ng pag-iimbak ng oras sa database ay direktang nakakaapekto sa performance ng mga query, pagiging kumplikado ng code, at kawastuhan ng pagtatrabaho sa mga time zone. Unix Timestamp — ang pinaka-epektibong format para sa relational databases: ito ay naka-imbak bilang integer (4 o 8 bytes), sumusuporta sa indexing at mabilis na pag-uuri. Hindi tulad ng ISO 8601 strings, ang timestamp ay hindi nangangailangan ng parsing sa pag-uuri at sumasakop ng mas kaunting espasyo sa index. Para sa Room at SQLite, inirerekomenda na i-imbak ang timestamp sa INTEGER type at gumamit ng index sa column ng oras.

Mga Rekomendasyon para sa Mobile Projects

Para sa mga Android application na may Room library, inirerekomenda na i-imbak ang timestamp bilang Long (64-bit) at gumamit ng TypeConverter para sa awtomatikong conversion sa pagitan ng Long at Date o Instant. Sa mga database query, gamitin ang mga comparison operator (>, <, BETWEEN) — gumagana ang mga ito nang native sa mga numeric type. Para sa pag-cache ng data na nangangailangan ng pag-uuri ayon sa oras (halimbawa, listahan ng mensahe), siguraduhing gumawa ng index sa timestamp column — mapapabilis nito ang mga query na may ORDER BY ng ilang order ng magnitude sa malalaking volume ng data.