Unix Timestamp: шта је, конверзија и складиштење у мобилној развоју

Шта је Unix Timestamp?

Unix Timestamp (такође познат као POSIX time, Epoch time или Unix time) — је систем мерења времена који одређује број секунди које су прошле од 1. јануара 1970. 00:00:00 UTC (епоха Unix-а). Овај датум је изабран као почетак бројања за оперативни систем Unix, и касније је формат постао де факто стандард за представљање времена у рачунарским системима. Timestamp не узима у обзир преступне секунде — сваки минут се рачуна као 60 секунди, иако Међународна служба за ротацију Земље понекада додаје додатну секунду за корекцију атомског времена.

Епоха Unix-а: зашто 1970.?

Избор 1. јануара 1970. везан је за историју развоја оперативног система Unix. Развојачи Ken Thompson и Dennis Ritchie одабрали су овај датум као једноставан и округао полазиште — био је довољно ран да обухвати све могуће датуме, и истовремено довољно каснида се време могло чувати у 32-битном прозначеном цијелом броју. Првобитно се време мерило у шеседесетим деловима секунде, затим у тиковима (1/60 секунде), и тек у седмом издању Unix-а (V7, 1979.) формат се стабилизовао као цијели број секунди. Према The Open Group Base Specifications (Issue 8, 2024), POSIX-компатибилни системи су обавезни да подржавају овај формат.

Како ради Unix Timestamp

Принцип рада Unix Timestamp-а заснива се на једноставном бројачу: сваки протекли дан додаје 86 400 секунди на вредност. На примјер, timestamp 1 720 000 000 одговара датуму у средини 2024. године — тачна конверзија се може извршити дељењем са бројем секунди у дану, сату и минуту. Овакав приступ чини timestamp идеалним за машинско складиштење: то је цијели број који заузима 4 бајта (32-битни int) или 8 бајтова (64-битни long) и подржава директно поређење — већи timestamp = каснији датум.

Математика конверзије

Један дан = 86 400 секунди (24 x 60 x 60). Један сат = 3600 секунди. Да бисте конвертовали timestamp у датум, потребно је узастопно израчунати број дана, сати, минута и секунди од почетка епохе. Обрнута конверзија — претворити датум у дане од 1970-01-01, затим помножити са 86 400 и додати помак у односу на UTC. У Java-и и Kotlin-у ове калкулације су већ имплементиране у стандардним класама java.time.Instant и java.util.Date, што ослобађа развојача од ручних прорачуна.

        // Добијте Unix Timestamp у секундама
val seconds = System.currentTimeMillis() / 1000

// Конвертујте timestamp у датум преко java.time
val instant = Instant.ofEpochSecond(seconds)
val localDate = instant.atZone(ZoneId.of("Europe/Moscow")).toLocalDate()

// Обрнуто: датум у timestamp
val date = LocalDate.of(2026, 7, 21)
val ts = date.atStartOfDay(ZoneOffset.UTC).toEpochSecond()

Конверзија Unix Timestamp-а у датум и обрнуто

Конверзија Unix Timestamp-а у људски читљив датум једна је од најчешћих операција у мобилном развоју. На Android-у је доступно неколико начина конверзије у зависности од минималне API верзије: за API 26+ се препоручује java.time.Instant, за старије верзије се користи java.util.Date и java.text.SimpleDateFormat. Важно је запамтити да Android и JVM подразумевано користе милисекунде, а не секунде — ако је timestamp примљен са сервера у секундама, потребно га је помножити са 1000 пре прослеђђивања стандардним конструкторима.

Конверзија са временском зоном корисника

Јдна од главних предности Unix Timestamp-а је независност од локације. Сервер увијек враћа timestamp у UTC-у, а конверзија у локални датум и време се обавља на страни клијента. У Kotlin-у за ово се користи ZonedDateTime са одговарајућим ZoneId-ом — системским или изабраним од стране корисника. Ако апликација приказује време у различитим зонама (на примјер, за путнике), timestamp елиминише потребу за слањем временске зоне са сервера — један временски ознак је довољан.

// Конверзија са временском зоном корисника
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))
}

// Примјер: timestamp = 1720000000, зона = Europe/Moscow
val result = formatTimestamp(1720000000, ZoneId.of("Europe/Moscow"))

Проблем 2038. године

Проблем 2038. године (Year 2038 Problem, Y2K38) — фундаментално ограничење 32-битног прозначеног цијелог броја за чување Unix Timestamp-а. Максимална вредност 32-битног signed int-а је 2 147 483 647, што одговара 19. јануару 2038. у 03:14:07 UTC. Након овог датума вредност се препуњава и претвара се у негативан број, што изазива кварове у системима који користе 32-битни time_t. Проблем је сличан познатом Y2K-у, али првенствено погађа уграђене системе, старије верзије Android-а и IoT уређаје са 32-битном архитектуром.

Обим проблема

Према Linux Foundation (2025), око 15% Linux уређаја у индустријском и IoT сегменту још увијек користи 32-битне компилације. За Android уређаје ризик је мањи — већина модерних паметних телефона ради на 64-битним процесорима (ARM64), али старији модели са Android 4.x и ниже могу користити 32-битни time_t. Рјешење проблема — миграција на 64-битни time_t, који је сигуран до 292 милијарде година. Од Android 5.0 (API 21) надаље, сви уређаји користе 64-битно време на нивоу језгра. Развојачима мобилних апликација је довољно да чувају timestamp у Long (64-битним) типу да би избегли проблема на нивоу апликације.

Рад са Unix Timestamp-ом у Android-у

У Android развоју, правилан рад са Unix Timestamp-ом је критичан за синхронизацију података, приказ времена пријема порука, рачунање тајмаута и планирање обавештења. Системски позив System.currentTimeMillis() враћа тренутно време у милисекундама од Unix епохе — то је најпрецнији извор времена доступан на уређају. За мрежне захтеве обично се користи Unix Timestamp у секундама, јер већина REST API-а и база података ради управо са секундама.

Препоручене праксе

Никада не користите System.currentTimeMillis() за мерење интервала — за то постоји System.nanoTime(), која је монотона и не зависи од промена сата од стране корисника. За приказ времена, увијек чувајте timestamp у UTC-у и конвертујте га у локалну временску зону на страни корисничког интерфејса. При раду са базама података (SQLite, Room) користите тип INTEGER и чувајте timestamp у секундама — то заузима 8 бајтова (Long) и подржава нативно SQL сортирање. За серијализацију у JSON-у препоручује се слање timestamp-а као броја (Long), а не низа — то је компактније и брже се парсира.

// Исправно мерење времена извршавања
val start = System.nanoTime()
// ... операција ...
val elapsed = System.nanoTime() - start
val seconds = elapsed / 1_000_000_000.0

// Чувајте у Room-у (Entity)
@Entity
data class Message(
    @PrimaryKey val id: Long,
    val text: String,
    val createdAt: Long // Unix Timestamp у секундама
)

Обрада времена са сервера

При пријему Unix Timestamp-а са сервера увијек провјерите јединицу мере: неки API-ји враћају милисекунде (компатибилни са JavaScript-ом), други — секунде (POSIX стандард). Разумијевање о јединицама мора бити забележено у API документацији. У одговору сервера, timestamp може бити прослеђђен као Long (JSON број) или String (ISO 8601). За дебагирање, додајте помоћну функцију која приказује timestamp у људски читљивом формату — то поједностављује провјеру исправности временских ознака током развоја.

Чување временских ознака у базама података

Избор формата чувања времена у бази података директно утиче на перформансе упита, сложеност кода и исправност рада са временским зонама. Unix Timestamp — најефикаснији формат за релационе базе података: чува се као цијели број (4 или 8 бајтова), подржава индексирање и брзо сортирање. За разлику од ISO 8601 низова, timestamp не захтева парсирање при сортирању и заузима мање простора у индексу. За Room и SQLite препоручује се чување timestamp-а у INTEGER типу и коришчење индекса на колони времена.

Препоруке за мобилне пројекте

За Android апликације са Room библиотеком, препоручује се чување timestamp-а као Long (64-битни) и коришчење TypeConverter-а за аутоматску конверзију између Long-а и Date-а или Instant-а. При упитима базе података користите операторе поређења (>, <, BETWEEN) — они раде нативно са нумеричким типовима. За кеширање података који захтевају сортирање по времену (на примјер, листа порука), обавезно направите индекс на колони timestamp — то ће убрзати упите са ORDER BY за неколико редова величине при великим обимима података.