هي unix الطوابع أفضل طريقة لتخزين الطوابع?

Question

أنا دائما استخدام الطوابع يونيكس على كل شيء, ولكن أنا أتساءل إذا كان هناك طريقة أفضل.

ماذا كنت تستخدم لتخزين الطوابع و لماذا ؟

Answer 1

ومع ذلك اخترت لتخزين الطابع الزمني، من المهم تجنب المشاكل تفسير الإقليمية والمشاكل الوقت الإزاحة. يتم تفسير الطابع الزمني يونكس نفسها بغض النظر عن المنطقة، ويتم احتساب من نفس النقطة في الوقت المناسب بغض النظر عن المنطقة الزمنية - وهذه هي الأشياء الجيدة

وحذار تخزين الطوابع كسلاسل غامضة مثل 01/02/2008، منذ ذلك يمكن أن يفسر على أنه 2 يناير 2008 أو 1 فبراير 2008، اعتمادا على لغة.

عند تخزين ساعة / دقيقة / ثانية، فمن المهم أن نعرف "التي" / الثانية يتم تحديد ساعة / دقيقة. يمكنك القيام بذلك عن طريق بما في ذلك المعلومات التوقيت (لا حاجة للطابع زمني يونيكس، منذ يفترض أن تكون UTC).

ولكن، لاحظ أن الطوابع الزمنية يونكس لا يمكن أن تمثل فريد بعض اللحظات في الوقت المناسب: عندما يكون هناك قفزة الثانية في UTC، لا يغير الطابع الزمني يونكس، لذلك كل 23:59:60 UTC و00:00:00 في اليوم التالي لها نفس التمثيل يونكس. حتى إذا كنت حقا بحاجة الى ثانية واحدة أو أفضل قرار، والنظر في شكل آخر.

إذا كنت تفضل صيغة قابلة للقراءة أكثر إنسانية للتخزين من الطابع الزمني يونكس، والنظر في ISO 8601 .

وأسلوب واحد التي تساعد على إبقاء الامور في نصابها الصحيح إلى الأمام لتخزين التواريخ كما UTC وتنطبق فقط التوقيت أو DST إزاحة عند عرض التاريخ إلى المستخدم.

Answer 2

إذا كنت تخزين ملف السجل، يرجى لحب بيت جعله شيئا الإنسان للقراءة ومفرداتيا-للفرز.

و2008-10-07 09:47:02 على سبيل المثال.

Answer 3

32 بت الطوابع يونكس سوف تفيض في غضون سنوات قليلة (يناير 2038) ، بحيث القوة يكون النظر. أنا عموما استخدام تنسيق DATETIME في SQL، وهو YYYY-MM-DD HH: MM: SS مع الوقت وعلى مدار الساعة على مدار 24 ساعة. وأنا أحاول أن الإخراج إلى الملفات في نفس الشكل، فقط لجعل حياتي أسهل.

Answer 4

وماذا حقبة لا تحتاج لتخزين وإلى أي قرار؟ إذا كنت بحاجة إلى ميكروثانية، أو التواريخ في time_t العصر الحجري قد لا يكون أفضل. لأغراض تجارية عامة انها جيدة جدا (على افتراض 64bit) عن

Answer 5

وذلك يعتمد على ما كنت في حاجة إلى الطوابع الزمنية ل.

وA يونيكس الزمني لا يمكن أن تمثل في الوقت 1 ثانية بعد 2008-12-31T23: 59: 59Z. إذا كنت تفعل "2009-01-01T09: 00: 00 '-' 2008-12-31T09: 00: 00 'مع يونيكس الطوابع والنتيجة هي غير صحيحة: لن يكون هناك نقلة الثانية بين هذين التاريخين وانهم منفصلون من 86401 ثانية (لا 86400 كما الطوابع الزمنية يونكس وسوف اقول لكم).

وبخلاف ذلك، وما قالت المستجيبين أخرى، نعم - الطوابع يونيكس هي وسيلة للذهاب:)

Answer 6

وA الطابع الزمني ليست فكرة جيدة على قواعد البيانات، لأنها لا تأخذ الصيفي أو التوقيت المحلي الحالي في الاعتبار. على الخلية فمن الأفضل لتخزينه كما كل مرة، ثم استخدم في الخلية التاريخ والوقت وظائف لإستعادة الأجزاء التي تريدها، أو مقارنة تواريخ أخرى.

Answer 7

وtimeval على غرار (time_t + ميكروثانية) إذا كنت بحاجة إلى دقة الفرعية الثانية، وإلا مجرد time_t. يمكنك استخدام قيمة عدد صحيح 64 بت لتخزين time_t * 1000000 + يو اس اي سي وكنت تجاوز برهان لأكثر من 292،000 +/- سنوات.

Answer 8

UNIX Timestamp 32 بت ويبدو أن مشكلة مزعج جدا بالنسبة للمستخدمين الذين إدخال تواريخ مستقبلية في 2038+.

إما استخدام التاريخ والوقت تسلسل الخلية أو تخزين التواريخ كما BIGINT(8) غير موقعة (ماكس:18 كوينتيليون) أو تطفو بحيث يمكنك إدخال أعداد كبيرة.ثم لا يمكنك استخدام على سبيل المثال PHP تاريخ() وظيفة لأنه يسمح فقط الأعداد الصحيحة كما المعلمة (محدودة من أنظمة 32-بت).

الحل وجدت هو استخدام PHP 5.2.0 المهام. ها هو التاريخ والوقت PHP الحل.

لا تحتاج إلى تغيير UNIX_TIMESTAMP الشكل.طالما لديك BIGINT(8) غير موقعة باسم MySQL الخاص بك لتخزين الطوابع الزمنية.لن تكون محدودة من قبل أنظمة 32 بت بعد الآن.

Answer 9

زمني هو bascially:

• متميزة نقطة في الوقت المناسب

و كنقطة في وقت قد لا نهاية لها القرار ، الشيء المهم في اختيار تنسيق الطابع الزمني هي:لديه ما يكفي من القرار ؟

• Unix الوقت التهم فقط في ثوان.
• Ext 4 وقد نانو ثانية
• جافا وقد نانو ثانية

بالنسبة لمعظم التطبيقات لدي نانو ثانية كانت كافية.لذا جافا الزمني كان القرار الصحيح بالنسبة لي حتى الآن.