ទម្រង់ត្រាពេលវេលា

មាតិកា៖

• សង្ខេប
  • បញ្ហា
  • ការសម្រេចចិត្ត
  • ស្ថានភាព
• ព័ត៌មានលម្អិត
  • ការសន្មត់
  • ឧបសគ្គ
  • ជំហរ
  • អាគុយម៉ង់
  • ផលវិបាក
• ពាក់ព័ន្ធ
  • ការសម្រេចចិត្តពាក់ព័ន្ធ
  • តម្រូវការពាក់ព័ន្ធ
  • វត្ថុពាក់ព័ន្ធ
  • គោលការណ៍ពាក់ព័ន្ធ
• កំណត់ចំណាំ

សង្ខេប

បញ្ហា

យើងចង់អាចតាមដានពេលដែលអ្វីៗកើតឡើង ដោយប្រើត្រាពេលវេលា និងប្រើទម្រង់ត្រាពេលវេលាដែលស៊ីសង្វាក់ ដែលដំណើរការបានល្អនៅទូទាំងប្រព័ន្ធទាំងអស់របស់យើង និងប្រព័ន្ធរបស់ភាគីទីបី។

យើងធ្វើអន្តរកម្មជាមួយប្រព័ន្ធដែលមានទម្រង់ត្រាពេលវេលាខុសគ្នា៖

• សារ JSON មិនមានទម្រង់ត្រាពេលវេលាដើមកំណើតទេ ដូច្នេះយើងត្រូវជ្រើសរើសរបៀបបម្លែងត្រាពេលវេលាទៅជាខ្សែអក្សរ និងបម្លែងខ្សែអក្សរទៅជាត្រាពេលវេលា ពោលគឺរបៀប serialize/deserialize។

• កម្មវិធីខ្លះត្រូវបានកំណត់ឱ្យប្រើម៉ោងក្នុងស្រុក ជាជាងម៉ោង UTC។ នេះអាចងាយស្រួលសម្រាប់គម្រោងដែលត្រូវកែតម្រូវទៅតាមម៉ោងក្នុងស្រុក ដូចជាគម្រោងដែលបង្កព្រឹត្តិការណ៍ផ្អែកលើម៉ោងក្នុងស្រុក។

• ប្រព័ន្ធខ្លះមានតម្រូវការ និងសមត្ថភាពភាពជាក់លាក់នៃពេលវេលាខុសគ្នា ដូចជាប្រើដំណោះស្រាយពេលវេលាជាវិនាទី ប្រៀបធៀបមីលីវិនាទី ប្រៀបធៀបណាណូវិនាទី។ ឧទាហរណ៍ ពាក្យបញ្ជា date របស់ប្រព័ន្ធប្រតិបត្តិការ Linux ប្រើភាពជាក់លាក់នៃពេលវេលាលំនាំដើមជាវិនាទី ចំណែកផ្សារហ៊ុន Nasdaq ចង់បានភាពជាក់លាក់នៃពេលវេលាលំនាំដើមជាណាណូវិនាទី។

ការសម្រេចចិត្ត

យើងជ្រើសរើសទម្រង់ស្តង់ដារត្រាពេលវេលា ISO 8601 ជាមួយភាពជាក់លាក់ណាណូវិនាទី ជាពិសេស “YYYY-MM-DDTHH:MM:SS.NNNNNNNNNZ”។

ទម្រង់នេះបង្ហាញឆ្នាំ ខែ ថ្ងៃ ម៉ោង នាទី វិនាទី ណាណូវិនាទី និងល្វែងម៉ោង Zulu ឬហៅថា UTC, GMT។

ស្ថានភាព

បានសម្រេច។

ព័ត៌មានលម្អិត

ការសន្មត់

យើងត្រូវដោះស្រាយខ្សែអក្សរអត្ថបទត្រាពេលវេលាទាំងនេះ ដើម្បីបម្លែងពីត្រាពេលវេលាទៅជាខ្សែអក្សរ (ឬហៅថា serialize) និងបម្លែងពីខ្សែអក្សរទៅជាត្រាពេលវេលា (ឬហៅថា deserialize)។

យើងចង់បានទម្រង់ដែលជាទូទៅងាយប្រើ ងាយបម្លែង និងងាយឱ្យមនុស្សអាន។

យើងចង់បានភាពត្រូវគ្នាជាមួយប្រព័ន្ធខាងក្រៅច្រើនប្រភេទដែលយើងមិនអាចគ្រប់គ្រង ដូចជាប្រព័ន្ធវិភាគ ប្រព័ន្ធមូលដ្ឋានទិន្នន័យ ប្រព័ន្ធហិរញ្ញវត្ថុ។

ឧបសគ្គ

ប្រព័ន្ធខ្លះមានដែនកំណត់ភាពជាក់លាក់នៃពេលវេលា។ ឧទាហរណ៍ ពាក្យបញ្ជា date របស់ប្រព័ន្ធប្រតិបត្តិការ macOS អាចបោះពុម្ពភាពជាក់លាក់នៃពេលវេលាជាវិនាទី ប៉ុន្តែមិនមែនជាណាណូវិនាទីទេ។

ជំហរ

យើងបានពិចារណាជម្រើសជាច្រើន៖

• Unix epoch ពោលគឺលេខតែមួយដែលកើនឡើង។

• ទម្រង់អត្ថបទខ្លី “YYYYMMDDTHHMMSSNNNNNNNNN”។

• ការប្រើល្វែងម៉ោងក្នុងស្រុក ប្រៀបធៀបល្វែងម៉ោង UTC។

អាគុយម៉ង់

សម្រាប់ការប្រើប្រាស់ធម្មតា យើងឱ្យតម្លៃលើភាពងាយអាន/សរសេរដោយមនុស្ស ច្រើនជាងល្បឿន/ទំហំដើម។

សម្រាប់ការប្រើប្រាស់ធម្មតា យើងចង់បានទម្រង់ដែលដំណើរការបានល្អក្នុងប្រព័ន្ធម៉ាស៊ីន ហើយក៏ដំណើរការបានល្អដោយដៃដែរ ដូចជាការសរសេរទិន្នន័យគំរូ ការអានលទ្ធផល JSON ការ grep ឯកសារកំណត់ហេតុ ។ល។

សម្រាប់ការប្រើប្រាស់មិនធម្មតា ដូចជាកុំព្យូទ័រប្រសិទ្ធភាពខ្ពស់ យើងរំពឹងថាយើងនឹងចង់ធ្វើឱ្យទម្រង់អត្ថបទណាមួយដែលយើងជ្រើសមានប្រសិទ្ធភាពល្អបំផុត ដោយបម្លែងអត្ថបទទៅជាទម្រង់លឿនជាង ដូចជាប្រភេទវត្ថុកាលបរិច្ឆេទភ្ជាប់មកស្រាប់របស់ភាសាសរសេរកម្មវិធី។ ដូច្នេះទម្រង់អត្ថបទមិនសំខាន់ច្រើនសម្រាប់ HPC ទេ។

ផលវិបាក

ប្រព័ន្ធអត្ថបទ និងប្រព័ន្ធពេលវេលាផ្សេងៗរបស់យើងនឹងបង្រួបបង្រួមទៅលើទម្រង់នេះ។

ពាក់ព័ន្ធ

ការសម្រេចចិត្តពាក់ព័ន្ធ

យើងអាចចង់បានវិធីលឿន/ងាយស្រួលក្នុងការតាមដានដែលរង្វង់ពេលវេលា ឬហៅថារយៈពេលផងដែរ។ ទាំងនេះងាយស្រួលជាមួយត្រាពេលវេលា Unix epoch។

តម្រូវការពាក់ព័ន្ធ

យើងអាចចង់កែសម្រួលការសម្រេចចិត្តរបស់យើង ឧ. ប្រសិនបើយើងមានតម្រូវការពាក់ព័ន្ធសម្រាប់ប្រភេទត្រាសារកំណត់ហេតុជាក់លាក់ ដូចជាសម្រាប់ Splunk, Sumo, ELK ។ល។

វត្ថុពាក់ព័ន្ធ

កម្មវិធីធ្វើទម្រង់ និងកម្មវិធីវិភាគភាសា៖

• date-fns: Modern JavaScript date utility library
• Crono: date and time library for Rust

ឧទាហរណ៍ Rosetta Code៖

• System time
• Data format
• Show the epoch

ឧទាហរណ៍ SixArm៖

• now_string

គោលការណ៍ពាក់ព័ន្ធ

អាចត្រឡប់វិញបានយ៉ាងងាយ។ យើងអាចផ្លាស់ប្តូរទៅទម្រង់ផ្សេងបានយ៉ាងងាយស្រួល ដូចជា Unix epoch។

ពន្យារការធ្វើឱ្យល្អបំផុតមុនកាលអាន់។ សម្រាប់ការប្រើប្រាស់ធម្មតា យើងមិនខ្វល់ច្រើនអំពីតួអក្សរបន្ថែមមួយចំនួនតូច ដូចជាទម្រង់ដែលប្រើសញ្ញាដាច់ និងសញ្ញាចុច។

កំណត់ចំណាំ

បន្ថែមកំណត់ចំណាំនៅទីនេះ។