Unix Timestamp: τι είναι, μετατροπή και αποθήκευση στην ανάπτυξη εφαρμογών για κινητά

Τι είναι το Unix Timestamp;

Unix Timestamp (γνωστό και ως POSIX time, Epoch time ή Unix time) — είναι ένα σύστημα μέτρησης χρόνου που ορίζει τον αριθμό δευτερολέπτων που έχουν περάσει από την 1η Ιανουαρίου 1970 00:00:00 UTC (εποχή Unix). Αυτή η ημερομηνία επιλέχθηκε ως αρχή μέτρησης για το λειτουργικό σύστημα Unix, και στη συνέχεια η μορφή έγινε το de facto πρότυπο για την αναπαράσταση χρόνου σε υπολογιστικά συστήματα. Το Timestamp δεν λαμβάνει υπόψη δίσεκτα δευτερόλεπτα — κάθε λεπτό θεωρείται 60 δευτερόλεπτα, αν και η Διεθνής Υπηρεσία Περιστροφής της Γης μερικές φορές προσθέτει ένα επιπλέον δευτερόλεπτο για διόρθωση του ατομικού χρόνου.

Εποχή Unix: γιατί το 1970;

Η επιλογή της 1ης Ιανουαρίου 1970 σχετίζεται με την ιστορία ανάπτυξης του λειτουργικού συστήματος Unix. Οι προγραμματιστές Ken Thompson και Dennis Ritchie επέλεξαν αυτήν την ημερομηνία ως μια απλή στρογγυλή μέτρηση — ήταν αρκετά νωρίς για να χωρέσει όλες τις πιθανές ημερομηνίες, και ταυτόχρονα αρκετά αργά ώστε ο χρόνος να μπορεί να αποθηκευτεί σε 32-bit signed ακέραιο αριθμό. Αρχικά ο χρόνος μετριόταν σε εξηκοστά του δευτερολέπτου, στη συνέχεια σε ticks (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 byte (32-bit int) ή 8 byte (64-bit 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, zone = Europe/Moscow
val result = formatTimestamp(1720000000, ZoneId.of("Europe/Moscow"))

Το πρόβλημα του 2038

Το πρόβλημα του 2038 (Year 2038 Problem, Y2K38) — ένας θεμελιώδης περιορισμός του 32-bit signed ακέραιου αριθμού για αποθήκευση Unix Timestamp. Η μέγιστη τιμή 32-bit signed int είναι 2 147 483 647, που αντιστοιχεί στις 19 Ιανουαρίου 2038 03:14:07 UTC. Μετά από αυτήν την ημερομηνία η τιμή υπερχειλίζει και γίνεται αρνητικός αριθμός, προκαλώντας σφάλματα σε συστήματα που χρησιμοποιούν 32-bit time_t. Το πρόβλημα είναι παρόμοιο με το γνωστό Y2K, αλλά επηρεάζει κυρίως ενσωματωμένα συστήματα, παλαιές εκδόσεις Android και συσκευές IoT με 32-bit αρχιτεκτονική.

Κλίμακα του προβλήματος

Σύμφωνα με το Linux Foundation (2025), περίπου το 15% των συσκευών Linux στον βιομηχανικό και IoT τομέα εξακολουθούν να χρησιμοποιούν 32-bit εκδόσεις. Για συσκευές Android ο κίνδυνος είναι μικρότερος — τα περισσότερα σύγχρονα smartphones λειτουργούν με 64-bit επεξεργαστές (ARM64), ωστόσο παλαιά μοντέλα με Android 4.x και κάτω μπορεί να χρησιμοποιούν 32-bit time_t. Η λύση του προβλήματος είναι η μετάβαση σε 64-bit time_t, το οποίο είναι ασφαλές για έως 292 δισεκατομμύρια χρόνια. Από το Android 5.0 (API 21) όλες οι συσκευές χρησιμοποιούν 64-bit χρόνο σε επίπεδο πυρήνα. Οι προγραμματιστές εφαρμογών για κινητά αρκεί να αποθηκεύουν timestamp σε τύπο Long (64-bit) για να αποφύγουν το πρόβλημα σε επίπεδο εφαρμογής.

Εργασία με Unix Timestamp σε Android

Στην ανάπτυξη Android, η σωστή διαχείριση του Unix Timestamp είναι κρίσιμη για συγχρονισμό δεδομένων, εμφάνιση ώρας λήψης μηνυμάτων, υπολογισμό timeouts και προγραμματισμό ειδοποιήσεων. Η συστημική κλήση System.currentTimeMillis() επιστρέφει την τρέχουσα ώρα σε χιλιοστά δευτερολέπτου από την εποχή Unix — αυτή είναι η πιο ακριβής πηγή χρόνου που είναι διαθέσιμη στη συσκευή. Για αιτήματα δικτύου συνήθως χρησιμοποιείται Unix Timestamp σε δευτερόλεπτα, καθώς τα περισσότερα REST API και βάσεις δεδομένων λειτουργούν με δευτερόλεπτα.

Συνιστώμενες πρακτικές

Ποτέ μην χρησιμοποιείτε System.currentTimeMillis() για μέτρηση διαστημάτων — για αυτό υπάρχει η System.nanoTime(), η οποία είναι μονότονη και δεν επηρεάζεται από αλλαγές ώρας από τον χρήστη. Για εμφάνιση ώρας πάντα αποθηκεύετε timestamp σε UTC και μετατρέπετε σε τοπική ζώνη ώρας στο UI. Κατά την εργασία με βάσεις δεδομένων (SQLite, Room) χρησιμοποιείτε τύπο INTEGER και αποθηκεύετε timestamp σε δευτερόλεπτα — αυτό καταλαμβάνει 8 byte (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 byte), υποστηρίζει ευρετηρίαση και γρήγορη ταξινόμηση. Σε αντίθεση με συμβολοσειρές ISO 8601, το timestamp δεν απαιτεί ανάλυση κατά την ταξινόμηση και καταλαμβάνει λιγότερο χώρο στο ευρετήριο. Για Room και SQLite συνιστάται η αποθήκευση timestamp σε τύπο INTEGER και η χρήση ευρετηρίου στη στήλη χρόνου.

Συστάσεις για έργα κινητών

Για εφαρμογές Android με βιβλιοθήκη Room συνιστάται η αποθήκευση timestamp ως Long (64-bit) και η χρήση TypeConverter για αυτόματη μετατροπή μεταξύ Long και Date ή Instant. Στα ερωτήματα προς τη βάση χρησιμοποιείτε τελεστές σύγκρισης (>, <, BETWEEN) — λειτουργούν εγγενώς με ακέραιους τύπους. Για προσωρινή αποθήκευση δεδομένων που απαιτούν ταξινόμηση κατά χρόνο (π.χ., λίστα μηνυμάτων), δημιουργήστε οπωσδήποτε ευρετήριο στη στήλη timestamp — αυτό θα επιταχύνει τα ερωτήματα με ORDER BY κατά αρκετές τάξεις μεγέθους σε μεγάλο όγκο δεδομένων.