| פורמט | שניות |
|---|---|
| GMT | Mon Aug 26 2024 15:46:52 GMT+0000 |
| אזור הזמן שלך | Mon Aug 26 2024 22:46:52 GMT+0700 (Indochina Time) |
| יחסי | 12 minutes ago |
Unix timestamp הוא דרך לעקוב אחרי זמן על ידי חיבור סך השניות. החישוב מתחיל מ- Unix Epoch ב- 1 בינואר 1970 ב- UTC. לכן, ה- Unix timestamp הוא פשוט מספר השניות שעברו מאז תאריך מסוים ועד ל- Unix Epoch. כדאי גם לציין (תודה להערות מבקרים באתר זה) כי נקודת הזמן הזו לא משתנה מבחינה טכנית לא משנה היכן אתה נמצא בעולם. זה מאוד שימושי עבור מערכות מחשוב לעקוב ולמיין מידע בזמן באפליקציות דינמיות ומפוזרות, הן באינטרנט והן בצד הלקוח.
| זמן קריא על ידי אדם | שניות |
|---|---|
| דקה אחת | 60 שניות |
| שעה אחת | 3600 שניות |
| יום אחד | 86400 שניות |
| שבוע אחד | 604800 שניות |
| חודש אחד (30.44 ימים) | 2629743 שניות |
| שנה אחת (365.24 ימים) | 31556926 שניות |
הבעיה של שנת 2038 (נקראת גם Y2038, Epochalypse, Y2k38, או Unix Y2K) קשורה לייצוג זמן במערכות דיגיטליות רבות ככמות השניות שחלפו מאז 00:00:00 UTC ב- 1 בינואר 1970 ואחסנתן כמספר שלם 32-ביט עם סימן. יישומים כאלה לא יכולים לקודד זמנים אחרי השעה 03:14:07 UTC ב- 19 בינואר 2038. בדומה לבעיה של Y2K, בעיית שנת 2038 נגרמת בגלל חוסר קיבולת בייצוג הזמן.
הזמן המאוחר ביותר מאז 1 בינואר 1970 שניתן לאחסן באמצעות מספר שלם 32-ביט עם סימן הוא 03:14:07 ביום שלישי, 19 בינואר 2038 (231-1 = 2,147,483,647 שניות אחרי 1 בינואר 1970). תוכניות שינסו להוסיף זמן מעבר לתאריך הזה יגרמו לאחסון הערך כמספר שלילי, שמערכות אלה יתפרשו כ- 20:45:52 ביום שישי, 13 בדצמבר 1901 (2,147,483,648 שניות לפני 1 בינואר 1970) במקום 19 בינואר 2038. זה קורה בגלל overflow של מספרים שלמים, שבו המונה יוצא מהתחום של הספרות הניתנות לשימוש, ומפנה את ביט הסימן במקום. זה מדווח על מספר שלילי מקסימלי, ואז המונה ממשיך לספור לכיוון אפס, ואז חוזר למספרים החיוביים. חישובים שגויים במערכות כאלה צפויים לגרום לבעיות למשתמשים ולצדדים תלויים אחרים.