Конвертер Unix Timestamp
Перетворена дата та час
Конвертер Unix-часів
Вступ
Unix-час (також відомий як POSIX-час або час Епохи) — це система для опису моменту часу. Це кількість секунд, що пройшли з 1 січня 1970 року (опівночі UTC/GMT), без урахування високосних секунд. Unix-часи широко використовуються в комп'ютерних системах і мовах програмування, оскільки вони забезпечують компактне, незалежне від мови представлення конкретного моменту часу.
Цей конвертер дозволяє вам перетворити Unix-час у зрозумілий для людини формат дати та часу. Він підтримує як 12-годинний (AM/PM), так і 24-годинний формати часу, щоб задовольнити різні регіональні та особисті уподобання.
Як працюють Unix-часи
Unix-часи обчислюються як кількість секунд з моменту Unix-Епохи (1 січня 1970 року, 00:00:00 UTC). Це робить їх особливо корисними для обчислення різниць у часі та для зберігання дат у компактному форматі.
Математичне перетворення з Unix-часу на календарну дату включає кілька етапів:
- Розпочніть з Unix-Епохи (1 січня 1970 року, 00:00:00 UTC)
- Додайте кількість секунд у часовій мітці
- Врахуйте високосні роки, різну довжину місяців та інші календарні складнощі
- Застосуйте коригування за часовим поясом, якщо потрібно
Наприклад, Unix-час 1609459200
представляє п'ятницю, 1 січня 2021 року, 00:00:00 UTC.
Формулу перетворення можна виразити так:
Більшість мов програмування та операційних систем надають вбудовані функції для обробки цього перетворення, абстрагуючи складні календарні обчислення.
Варіанти формату часу
Цей конвертер пропонує два варіанти формату часу:
-
24-годинний формат (іноді називається "військовим часом"): години варіюються від 0 до 23, і немає позначення AM/PM. Наприклад, 15:00 представляє 3:00 PM.
-
12-годинний формат: години варіюються від 1 до 12, з AM (ante meridiem) для часу з півночі до полудня, і PM (post meridiem) для часу з полудня до півночі. Наприклад, 15:00 у 24-годинному форматі представляє 3:00 PM.
Вибір між цими форматами в основному є питанням регіональної традиції та особистих уподобань:
- 24-годинний формат зазвичай використовується в більшості країн Європи, Латинської Америки та Азії, а також у наукових, військових і медичних контекстах по всьому світу.
- 12-годинний формат поширений у США, Канаді, Австралії та деяких інших англомовних країнах для повсякденного використання.
Країни та обмеження
При роботі з Unix-часами важливо бути обізнаним про кілька країн і обмежень:
-
Негативні часові мітки: вони представляють дати до Unix-Епохи (1 січня 1970 року). Хоча математично це дійсно, деякі системи можуть неправильно обробляти негативні часові мітки.
-
Проблема року 2038: Unix-часи часто зберігаються як 32-бітні знакові цілі числа, які переповняться 19 січня 2038 року. Після цього моменту системи з 32 бітами не зможуть правильно представляти час, якщо не будуть модифіковані для використання більшого типу цілого числа.
-
Надзвичайно великі часові мітки: дуже віддалені майбутні дати можуть бути непредставленими в деяких системах або можуть оброблятися непослідовно.
-
Високосні секунди: Unix-час не враховує високосні секунди, які час від часу додаються до UTC, щоб компенсувати нерегулярний оберт Землі. Це означає, що Unix-час не точно синхронізований з астрономічним часом.
-
Урахування часового поясу: Unix-часи представляють моменти в UTC. Перетворення на місцевий час вимагає додаткової інформації про часовий пояс.
-
Літній час: при конвертації часових міток у місцевий час необхідно враховувати складнощі переходів на літній час.
Варіанти використання
Unix-часи використовуються в численних застосунках у комп'ютерних та управлінських даних:
-
Записи в базі даних: часові мітки зазвичай використовуються для запису моментів створення або зміни записів.
-
Веб-розробка: заголовки HTTP, куки та механізми кешування часто використовують Unix-часи.
-
Лог-файли: системні журнали зазвичай записують події з Unix-часами для точного хронологічного порядку.
-
Системи контролю версій: Git та інші системи контролю версій використовують часові мітки для запису моментів комітів.
-
Відповіді API: багато веб-API включають часові мітки у своїх відповідях, щоб вказати, коли дані були згенеровані або коли ресурси були востаннє змінені.
-
Файлові системи: часи створення та зміни файлів часто зберігаються як Unix-часи.
-
Управління сесіями: веб-додатки використовують часові мітки, щоб визначити, коли сесії користувачів повинні закінчитися.
-
Аналіз даних: часові мітки забезпечують стандартизований спосіб роботи з тимчасовими даними в аналітичних застосунках.
Альтернативи
Хоча Unix-часи широко використовуються, існують альтернативні формати представлення часу, які можуть бути більш доречними в певних контекстах:
-
ISO 8601: стандартизований рядковий формат (наприклад, "2021-01-01T00:00:00Z"), який є зрозумілим для людини, зберігаючи при цьому можливість сортування. Він часто віддається перевазі для обміну даними та застосунків, орієнтованих на користувача.
-
RFC 3339: профіль ISO 8601, що використовується в інтернет-протоколах, з більш суворими вимогами до форматування.
-
Зрозумілі формати: локалізовані рядки дати (наприклад, "1 січня 2021 року") є більш доречними для прямої взаємодії з користувачем, але менш підходять для обчислень.
-
Microsoft FILETIME: 64-бітне значення, що представляє кількість інтервалів у 100 наносекунд з 1 січня 1601 року, використовується в системах Windows.
-
Юліанський день: використовується в астрономії та деяких наукових застосунках, підраховуючи дні з 1 січня 4713 року до нашої ери.
Вибір формату часу залежить від таких факторів, як:
- Необхідна точність
- Потреби в зрозумілості для людини
- Обмеження зберігання
- Сумісність з існуючими системами
- Діапазон дат, які потрібно представити
Історія
Концепція Unix-часу виникла з розробки операційної системи Unix у Bell Labs в кінці 1960-х і на початку 1970-х років. Рішення використовувати 1 січня 1970 року як епоху було дещо арбітрарним, але практичним для того часу — воно було достатньо близьким, щоб мінімізувати вимоги до зберігання для дат, що цікавлять, але достатньо далеким у минулому, щоб бути корисним для історичних даних.
Оригінальна реалізація використовувала 32-бітне знакове ціле число для зберігання кількості секунд, що було достатнім для очікуваного терміну служби Unix-систем у той час. Однак це рішення призвело до проблеми року 2038 (іноді називається "Y2K38" або "Unix Millennium Bug"), оскільки 32-бітні знакові цілі числа можуть представляти дати лише до 19 січня 2038 року (03:14:07 UTC).
Коли Unix та подібні до Unix операційні системи набули популярності, Unix-час став де-факто стандартом для представлення часу в обчисленні. Він був прийнятий численними мовами програмування, базами даних і застосунками, поширюючись далеко за межі свого початкового середовища Unix.
Сучасні системи все більше використовують 64-бітні цілі для часових міток, що розширює діапазон представлення приблизно на 292 мільярди років у обох напрямках від епохи, ефективно вирішуючи проблему року 2038. Однак застарілі системи та застосунки можуть все ще бути вразливими.
Простота та корисність Unix-часу забезпечили його тривалу актуальність, незважаючи на розвиток більш складних форматів представлення часу. Він залишається основоположною концепцією в обчисленні, що лежить в основі більшості нашої цифрової інфраструктури.
Приклади коду
Ось приклади того, як перетворити Unix-часи на зрозумілі для людини дати в різних мовах програмування:
// Конвертація часової мітки в JavaScript
function convertUnixTimestamp(timestamp, use12Hour = false) {
// Створіть новий об'єкт Date (JavaScript використовує мілісекунди)
const date = new Date(timestamp * 1000);
// Форматування
const options = {
year: 'numeric',
month: 'long',
day: 'numeric',
weekday: 'long',
hour: use12Hour ? 'numeric' : '2-digit',
minute: '2-digit',
second: '2-digit',
hour12: use12Hour
};
// Перетворення в рядок за допомогою локального форматування
return date.toLocaleString(undefined, options);
}
// Приклад використання
const timestamp = 1609459200; // 1 січня 2021 року 00:00:00 UTC
console.log(convertUnixTimestamp(timestamp, false)); // 24-годинний формат
console.log(convertUnixTimestamp(timestamp, true)); // 12-годинний формат
Обробка країн
При роботі з Unix-часами важливо правильно обробляти країни. Ось приклади обробки деяких поширених країн:
// Обробка країн у JavaScript
function safeConvertTimestamp(timestamp, use12Hour = false) {
// Перевірка на дійсність часової мітки
if (timestamp === undefined || timestamp === null || isNaN(timestamp)) {
return "Недійсна часова мітка";
}
// Перевірка на негативні часові мітки (дати до 1970)
if (timestamp < 0) {
// Деякі браузери можуть неправильно обробляти негативні часові мітки
// Використовуйте більш надійний підхід для дат до 1970
const date = new Date(timestamp * 1000);
if (isNaN(date.getTime())) {
return "Недійсна дата (до 1970)";
}
}
// Перевірка на проблему Y2K38 (для 32-бітних систем)
const maxInt32 = 2147483647; // Максимальне значення для 32-бітного знакового цілого
if (timestamp > maxInt32) {
// Розгляньте можливість використання BigInt для дуже великих часових міток у сучасному JavaScript
console.warn("Часова мітка перевищує обмеження 32-бітного цілого (проблема Y2K38)");
}
// Продовжити з нормальним перетворенням
try {
const date = new Date(timestamp * 1000);
const options = {
year: 'numeric',
month: 'long',
day: 'numeric',
weekday: 'long',
hour: use12Hour ? 'numeric' : '2-digit',
minute: '2-digit',
second: '2-digit',
hour12: use12Hour
};
return date.toLocaleString(undefined, options);
} catch (error) {
return "Помилка при конвертації часової мітки: " + error.message;
}
}
Посилання
-
"Unix Time." Wikipedia, Wikimedia Foundation, https://en.wikipedia.org/wiki/Unix_time
-
"Проблема року 2038." Wikipedia, Wikimedia Foundation, https://en.wikipedia.org/wiki/Year_2038_problem
-
Olson, Arthur David. "Складнощі календарного часу." The Open Group, https://www.usenix.org/legacy/events/usenix01/full_papers/olson/olson.pdf
-
"ISO 8601." Wikipedia, Wikimedia Foundation, https://en.wikipedia.org/wiki/ISO_8601
-
"RFC 3339: Дата та час в Інтернеті: часові мітки." Internet Engineering Task Force (IETF), https://tools.ietf.org/html/rfc3339
-
Kernighan, Brian W., and Dennis M. Ritchie. "Мова програмування C." Prentice Hall, 1988.