දිවා කාල වේලාවක් හෝ කාලරාමු ක්ෂේත්‍රයක් භාවිතා කිරීමට ඔබ නිර්දේශ කරනවාද ? (MySQL භාවිතා කිරීම) ඇයි?

මම සේවාදායක පැත්තේ PHP සමඟ වැඩ කරමි.

MySQL හි කාලරාමු සාමාන්‍යයෙන් වාර්තා වල වෙනස්කම් නිරීක්ෂණය කිරීමට භාවිතා කරන අතර බොහෝ විට වාර්තාව වෙනස් වන සෑම විටම යාවත්කාලීන වේ. ඔබට නිශ්චිත අගයක් ගබඩා කිරීමට අවශ්‍ය නම් ඔබ දිවා කාලයේ ක්ෂේත්‍රයක් භාවිතා කළ යුතුය.

ඔබ අදහස් කළේ යුනික්ස් කාලරාමුව හෝ ස්වදේශික MySQL දිවා කාල ක්ෂේත්‍රය භාවිතා කිරීම අතර තීරණය කිරීමට ඔබට අවශ්‍ය නම්, ස්වදේශීය ආකෘතිය සමඟ යන්න. ඔබට MySQL තුළ ඒ ආකාරයෙන් ගණනය කිරීම් කළ හැකි ("SELECT DATE_ADD(my_datetime, INTERVAL 1 DAY)")අතර ("SELECT UNIX_TIMESTAMP(my_datetime)")ඔබට PHP සමඟ ක්‍රියාත්මක වීමට අවශ්‍ය නම් වාර්තාව විමසන විට වටිනාකමෙහි ආකෘතිය යුනික්ස් කාලරාමුවකට වෙනස් කිරීම සරල ය .

MySQL 5 සහ ඊට ඉහළින්, TIMESTAMP අගයන් ගබඩා කිරීම සඳහා වත්මන් කාල කලාපයේ සිට UTC බවට පරිවර්තනය කර නැවත ලබා ගැනීම සඳහා UTC වෙතින් වත්මන් කාල කලාපයට පරිවර්තනය කරනු ලැබේ. (මෙය සිදුවන්නේ TIMESTAMP දත්ත වර්ගය සඳහා මිස DATETIME වැනි වෙනත් වර්ග සඳහා නොවේ .)

පෙරනිමියෙන්, එක් එක් සම්බන්ධතාවය සඳහා වත්මන් කාල කලාපය සේවාදායකයාගේ කාලය වේ. MySQL සේවාදායක කාල කලාප සහයෙහි විස්තර කර ඇති පරිදි කාල කලාපය එක් එක් සම්බන්ධතාවය අනුව සැකසිය හැකිය .

පේළි පාර-දත්ත (දිනය සාදන ලද හෝ වෙනස් කරන ලද) හැර වෙනත් ඕනෑම දෙයක් සඳහා මම සෑම විටම DATETIME ක්ෂේත්‍ර භාවිතා කරමි.

ලෙස සඳහන් වන MySQL ලියකියවිලි වල:

දිනය සහ වේලාව යන දෙකම අඩංගු අගයන් ඔබට අවශ්‍ය විට DATETIME වර්ගය භාවිතා වේ. MySQL විසින් DATETIME අගයන් 'YYYY-MM-DD HH: MM: SS' ආකෘතියෙන් ලබා ගනී. සහාය දක්වන පරාසය '1000-01-01 00:00:00' සිට '9999-12-31 23:59:59' වේ.

...

TIMESTAMP දත්ත වර්ගයට '1970-01-01 00:00:01' UTC සිට '2038-01-09 03:14:07' UTC පරාසයක් ඇත. MySQL අනුවාදය සහ සේවාදායකය ක්‍රියාත්මක වන SQL මාදිලිය මත පදනම්ව එයට විවිධ ගුණාංග ඇත.

සාමාන්‍ය භාවිතයේදී ඔබ TIMESTAMPs හි පහළ සීමාවට පැමිණීමට බොහෝ දුරට ඉඩ ඇත - උදා: උපන් දිනය ගබඩා කිරීම.

TIMESTAMPවෙනස් නොවන time-zone to 'america/new_york'ස්ථානය වෙනස් කිරීමෙන් පසු දිනය වර්ගය අගයන් වෙනස් කළ ආකාරය පහත උදාහරණ වලින් දැක්වේ DATETIME.

mysql> show variables like '%time_zone%';
+------------------+---------------------+
| Variable_name    | Value               |
+------------------+---------------------+
| system_time_zone | India Standard Time |
| time_zone        | Asia/Calcutta       |
+------------------+---------------------+

mysql> create table datedemo(
    -> mydatetime datetime,
    -> mytimestamp timestamp
    -> );

mysql> insert into datedemo values ((now()),(now()));

mysql> select * from datedemo;
+---------------------+---------------------+
| mydatetime          | mytimestamp         |
+---------------------+---------------------+
| 2011-08-21 14:11:09 | 2011-08-21 14:11:09 |
+---------------------+---------------------+

mysql> set time_zone="america/new_york";

mysql> select * from datedemo;
+---------------------+---------------------+
| mydatetime          | mytimestamp         |
+---------------------+---------------------+
| 2011-08-21 14:11:09 | 2011-08-21 04:41:09 |
+---------------------+---------------------+

මම මගේ පිළිතුර ලිපියක් බවට පරිවර්තනය කර ඇති බැවින් වැඩි පිරිසකට මෙම ප්‍රයෝජනවත්, MySQL: Datetime Versus Timeestamp Data Types සොයා ගත හැකිය .

ප්‍රධාන වෙනස වන්නේ DATETIME නියත වන අතර TIMESTAMP time_zoneසැකසුම කෙරෙහි බලපායි .

එබැවින් එය වැදගත් වන්නේ කාල කලාප හරහා සමමුහුර්ත කළ පොකුරු ඔබ සතුව ඇති විට හෝ අනාගතයේ දී පමණි.

සරල වචන වලින් කිවහොත්: මට ඕස්ට්‍රේලියාවේ දත්ත සමුදායක් තිබේ නම් සහ ඇමරිකාවේ දත්ත සමුදායක් සමමුහුර්ත කිරීමට / ජනගහනය කිරීමට එම දත්ත ගබඩාවේ කුණු කූඩයක් ගන්නවා නම්, ටයිම්ස්ටැම්ප් නව කාල කලාපයේ සිදුවීමේ සැබෑ වේලාව පිළිබිඹු වන පරිදි යාවත්කාලීන කරනු ඇති අතර DATETIME අවු කාල කලාපයේ සිදුවීමේ වේලාව තවමත් පිළිබිඹු කරයි .

ෆේස්බුක් හි TIMESTAMP භාවිතා කළ යුතු තැන DATETIME භාවිතා කිරීම පිළිබඳ හොඳ උදාහරණයක් වේ, එහිදී ඔවුන්ගේ සේවාදායකයන්ට කාල කලාප හරහා සිදු වූයේ කුමක්දැයි නිශ්චිතවම විශ්වාස නැත. වරක් මා සංවාදයක යෙදී සිටියදී පණිවිඩය යැවීමට පෙර මම පණිවිඩවලට පිළිතුරු දෙන බව පැවසුවා. (ඇත්ත වශයෙන්ම, මෙය සමමුහුර්තකරණයට වඩා වේලාවන් පළ කරනු ලැබුවේ නම් පණිවුඩකරණ මෘදුකාංගයේ නරක කාල කලාප පරිවර්තනය නිසා ද මෙය සිදුවිය හැකිය.)

මම මේ තීරණය ගන්නේ අර්ථකථන පදනමක් මතයි.

නියමිත වේලාවට (වැඩි හෝ අඩු) ස්ථාවර ස්ථානයක් සටහන් කිරීමට අවශ්‍ය විට මම කාලරාමුව භාවිතා කරමි. උදාහරණයක් ලෙස දත්ත ගබඩාවට වාර්තාවක් ඇතුළත් කළ විට හෝ යම් පරිශීලක ක්‍රියාවක් සිදු වූ විට.

දිනය / වේලාව අත්තනෝමතික ලෙස වෙනස් කර වෙනස් කළ හැකි විට මම දිවා කාල ක්ෂේත්‍රයක් භාවිතා කරමි. උදාහරණයක් ලෙස පරිශීලකයෙකුට පසුව වෙනස් කිරීම් හමුවීම් සුරැකිය හැක.

මම භාවිතා කිරීම නිර්දේශ වත් එය දිනයවේලාව හෝ අවකාශය ඇත්තේ පාලකයන්ට ක්ෂේත්රයේ. ඔබට සමස්තයක් ලෙස නිශ්චිත දිනයක් නියෝජනය කිරීමට අවශ්‍ය නම් (උපන් දිනය වැනි), පසුව DATE වර්ගයක් භාවිතා කරන්න, නමුත් ඔබ ඊට වඩා විශේෂිත නම්, ඒකකයකට වඩා සැබෑ මොහොතක් පටිගත කිරීමට ඔබ උනන්දු වනු ඇත. කාලය (දිනය, සතිය, මාසය, වර්ෂය). DATETIME හෝ TIMESTAMP භාවිතා කරනවා වෙනුවට, BIGINT භාවිතා කරන්න, සහ යුගයේ සිට මිලි තත්පර ගණනක් ගබඩා කරන්න (System.currentTimeMillis () ඔබ ජාවා භාවිතා කරන්නේ නම්). මෙය වාසි කිහිපයක් ඇත:

1. ඔබ විකුණුම්කරුවන්ගේ අගුළු දැමීමෙන් වළකින්න. සෑම දත්ත ගබඩාවක්ම සාපේක්ෂව සමාන ආකාරයකින් පූර්ණ සංඛ්‍යා සඳහා සහය දක්වයි. ඔබට වෙනත් දත්ත ගබඩාවකට යාමට අවශ්‍ය යැයි සිතමු. MySQL හි DATETIME අගයන් අතර ඇති වෙනස්කම් සහ ඔරකල් ඒවා නිර්වචනය කරන්නේ කෙසේද යන්න ගැන ඔබට කරදර වීමට අවශ්‍යද? MySQL හි විවිධ අනුවාදයන් අතර පවා, TIMESTAMPS හි වෙනස් මට්ටමේ නිරවද්‍යතාවයක් ඇත. කාලරාමුවල MySQL මිලි තත්පර සඳහා සහය දැක්වූයේ මෑතකදී ය.
2. කාල කලාප ගැටළු නොමැත. විවිධ දත්ත වර්ග සමඟ කාල කලාප සමඟ සිදුවන්නේ කුමක්ද යන්න පිළිබඳ තීක්ෂ්ණ බුද්ධිමත් අදහස් කිහිපයක් මෙහි ඇත. නමුත් මෙය පොදු දැනුමක්ද, ඔබේ සමකාලීනයන් සියල්ලන්ම එය ඉගෙන ගැනීමට කාලය ගත කරයිද? අනෙක් අතට, බිගින්ට් එකක් java.util.Date බවට වෙනස් කිරීම අවුල් කිරීම තරමක් අපහසුය. BIGINT භාවිතා කිරීම කාල කලාප සමඟ ගැටලු රාශියක් පාර අයිනේ වැටීමට හේතු වේ.
3. පරාසයන් හෝ නිරවද්‍යතාවය ගැන කරදර නොවන්න. අනාගත දින පරාසයන් අනුව අඩු කිරීම ගැන ඔබ කරදර විය යුතු නැත (TIMESTAMP යන්නේ 2038 දක්වා පමණි).
4. තෙවන පාර්ශවීය මෙවලම් ඒකාබද්ධ කිරීම. පූර්ණ සංඛ්‍යාවක් භාවිතා කිරීමෙන්, තෙවන පාර්ශවීය මෙවලම් (උදා: EclipseLink) දත්ත සමුදාය සමඟ අතුරුමුහුණත් කිරීම සුළුපටු ය. සෑම තෙවන පාර්ශවීය මෙවලමක්ම MySQL මෙන් “දිවා කාලය” පිළිබඳ අවබෝධයක් ලබා නොගනී. ඔබ මෙම අභිරුචි දත්ත වර්ග භාවිතා කරන්නේ නම් ඔබ java.sql.TimeStamp හෝ java.util.Date වස්තුවක් භාවිතා කළ යුතුද යන්න හයිබර්නේට් හි උත්සාහ කර බැලීමට අවශ්‍යද? ඔබගේ මූලික දත්ත වර්ග භාවිතා කිරීම තෙවන පාර්ශවීය මෙවලම් සමඟ භාවිතා කිරීම සුළුපටු නොවේ.

දත්ත සමුදායක් තුළ ඔබ මුදල් වටිනාකමක් (එනම් $ 1.99) ගබඩා කරන්නේ කෙසේද යන්න මෙම ගැටළුව සමීපව සම්බන්ධ වේ. ඔබ දශමයක් හෝ දත්ත සමුදායේ මුදල් වර්ගය භාවිතා කළ යුතුද? ඉහත ලැයිස්තුගත කර ඇති එකම හේතු බොහොමයක් නිසා මෙම විකල්ප 3 ම භයානක ය. විසඳුම වන්නේ මුදල් වටිනාකම BIGINT භාවිතයෙන් ශත තුළ ගබඩා කර පසුව ඔබ පරිශීලකයාට වටිනාකම පෙන්වන විට ශත ඩොලර් බවට පරිවර්තනය කිරීමයි. දත්ත සමුදායේ කාර්යය වන්නේ දත්ත ගබඩා කිරීම සහ එම දත්ත අර්ථ නිරූපණය කිරීම නොවේ. දත්ත සමුදායන්හි (විශේෂයෙන් ඔරකල්) ඔබ දකින මෙම විසිතුරු දත්ත වර්ග සියල්ලම එකතු නොකරන අතර විකුණුම්කරුවන්ගේ අගුළු දැමීමේ මාවතෙන් ඔබව ආරම්භ කරන්න.

TIMESTAMP යනු DATETIME සඳහා බයිට් 4 Vs 8 බයිට් වේ.

http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html

නමුත් ස්ක්‍රොනයිඩ් පැවසූ පරිදි එය 1970 වර්ෂයට වඩා අඩු සීමාවක් ඇත. අනාගතයේදී සිදුවිය හැකි ඕනෑම දෙයකට එය විශිෂ්ටයි;)

1. TIMESTAMP යනු DATETIME සඳහා බයිට් හතරක් එදිරිව බයිට් අටකි.

2. කාලරාමු ද දත්ත සමුදායේ සැහැල්ලු වන අතර වේගයෙන් සුචිගත කර ඇත.

3. දිනය සහ වේලාව යන දෙකම අඩංගු අගයන් ඔබට අවශ්‍ය විට DATETIME වර්ගය භාවිතා වේ. MySQL විසින් DATETIME අගයන් 'YYYY-MM-DD HH: MM: SS' ආකෘතියෙන් ලබා ගනී. සහාය දක්වන පරාසය '1000-01-01 00:00:00 ′ සිට' 9999-12-31 23:59:59 is වේ.

TIMESTAMP දත්ත වර්ගයට '1970-01-01 00:00:01 ′ UTC සිට' 2038-01-09 03:14:07 ′ UTC පරාසයක් ඇත. MySQL අනුවාදය සහ සේවාදායකය ක්‍රියාත්මක වන SQL මාදිලිය මත පදනම්ව එයට විවිධ ගුණාංග ඇත.

4. DATETIME නියත වන අතර TIMESTAMP ක්‍රියාත්මක වන්නේ කාල කලාප සැකසුම මගිනි.

යෙදුම මත රඳා පවතී.

සංගායි හි හමුවීමක් සඳහා පරිශීලකයෙකු විසින් නිව්යෝක්හි සේවාදායකයකට කාලරාමුව සැකසීම සලකා බලන්න. දැන් පරිශීලකයා සංගායි වෙත සම්බන්ධ වන විට, ඔහු ටෝකියෝ හි කැඩපත් සේවාදායකයකින් එම හමුවීම් කාලරාමුව වෙත ප්‍රවේශ වේ. ඔහු පත්වීම ටෝකියෝ වේලාවේදී දකිනු ඇත.

එබැවින් හමුවීමක් හෝ කාලසටහනක් වැනි පරිශීලක කාලය නියෝජනය කරන අගයන් සඳහා, දිවා කාලය වඩා හොඳය. සේවාදායක සැකසුම් නොසලකා පරිශීලකයාට අවශ්‍ය දිනය හා වේලාව පාලනය කිරීමට එය ඉඩ දෙයි. නියම කරන ලද වේලාව යනු සේවාදායකයාගේ කාල කලාපය, පරිශීලකයාගේ කාල කලාපය හෝ දිවා ආලෝකය ඉතිරි කිරීමේ කාලය ගණනය කරන ආකාරය වෙනස් කිරීම (ඔව් එය වෙනස් වේ).

අනෙක් අතට, ගෙවීම් ගනුදෙනු, වගු වෙනස් කිරීම් හෝ ලොග් වීම වැනි පද්ධති වේලාව නියෝජනය කරන අගයන් සඳහා, සෑම විටම කාලරාමු භාවිතා කරන්න. සේවාදායකය වෙනත් කාල කලාපයකට ගෙන යාමෙන් හෝ විවිධ කාල කලාපවල සේවාදායකයන් අතර සංසන්දනය කිරීමෙන් පද්ධතියට බලපෑමක් සිදු නොවේ.

කාලරාමු ද දත්ත සමුදායේ සැහැල්ලු වන අතර වේගයෙන් සුචිගත කර ඇත.

2016 + : මම උපදෙස් දෙන්නේ ඔබේ MySQL කාල කලාපය UTC ලෙස සකසා DATETIME භාවිතා කරන්න:

ඕනෑම මෑත ඉදිරිපස රාමුවකට (කෝණික 1/2, ප්‍රතික්‍රියා, Vue, ...) ඔබගේ UTC දිවා කාලය දේශීය වේලාවට පහසුවෙන් සහ ස්වයංක්‍රීයව පරිවර්තනය කළ හැකිය.

අමතරව:

• DATETIME දැන් ස්වයංක්‍රීයව වත්මන් කාල අගයට සැකසිය හැක. ඔබ MySQL Datetime තීරුව සඳහා පෙරනිමි අගයක් සකසන්නේ කෙසේද?
• යමෙකු සිතිය හැකි දෙයට පටහැනිව, DATETIME යනු ටයිම්ස්ටැම්ප් වලට වඩා වේගවත්ය, http://gpshumano.blogs.dri.pt/2009/07/06/mysql-datetime-vs-timestamp-vs-int-performance-and-benchmarking-with -මිසම් /
• TIMESTAMP තවමත් 1970-2038 දක්වා සීමා කර ඇත

(ඔබ ඔබේ සේවාදායකයන්ගේ කාල කලාපය වෙනස් කිරීමට ඉඩ නොමැති නම්)

AngularJs සමඟ උදාහරණය

// back-end: format for angular within the sql query
SELECT DATE_FORMAT(my_datetime, "%Y-%m-%dT%TZ")...

// font-end Output the localised time
{{item.my_datetime | date :'medium' }}

සියලුම දේශීයකරණය කළ කාල ආකෘතිය මෙහි ඇත: https://docs.angularjs.org/api/ng/filter/date

ඒ timestampකෙත විශේෂ නඩුව datetimeක්ෂේත්රයේ. timestampවිශේෂ ගුණාංග ලබා ගැනීම සඳහා ඔබට තීරු සෑදිය හැකිය ; එය නිර්මාණය කිරීම සහ / හෝ යාවත්කාලීන කිරීම මත යාවත්කාලීන කිරීමට සැකසිය හැක.

"විශාල" දත්ත සමුදායන් අනුව, timestampඑය මත විශේෂ අවස්ථා ප්‍රේරක කිහිපයක් ඇත.

නිවැරදි දෙය සම්පූර්ණයෙන්ම රඳා පවතින්නේ ඔබට කිරීමට අවශ්‍ය දේ මතය.

TIMESTAMP සැමවිටම UTC හි ඇත (එනම් 1970-01-01 සිට UTC හි ගත වූ තත්පර ගණන), සහ ඔබේ MySQL සේවාදායකය එය ස්වයංක්‍රීයව සම්බන්ධතා කාල කලාපය සඳහා දිනය / වේලාව බවට පරිවර්තනය කරයි. දිගු කාලීනව, TIMESTAMP යනු යා යුතු මාර්ගයයි, මන්ද ඔබේ තාවකාලික දත්ත සැමවිටම UTC හි පවතින බව ඔබ දන්නා බැවිනි. උදාහරණයක් ලෙස, ඔබ වෙනත් සේවාදායකයකට සංක්‍රමණය වුවහොත් හෝ ඔබේ සේවාදායකයේ කාල කලාප සැකසුම් වෙනස් කළහොත් ඔබ ඔබේ දිනයන් ඉස්කුරුප්පු නොකරනු ඇත.

සටහන: පෙරනිමි සම්බන්ධතා කාල කලාපය සේවාදායක කාල කලාපය වේ, නමුත් මෙය සැසියකට (කළ යුතු) වෙනස් කළ හැකිය (බලන්න SET time_zone = ...).

DATETIME, TIMESTAMP සහ DATE අතර සංසන්දනය

එය කුමක්ද?

• DATETIME හෝ TIMESTAMP අගයකට මයික්‍රෝ තත්පර (ඉලක්කම් 6) දක්වා නිරවද්‍යතාවයෙන් තත්පර භාගයක පසුපස කොටස ඇතුළත් කළ හැකිය. විශේෂයෙන්, DATETIME හෝ TIMESTAMP තීරුවකට ඇතුළත් කළ අගයක ඕනෑම භාගික කොටසක් ඉවතලනු වෙනුවට ගබඩා කර ඇත. මෙය ඇත්ත වශයෙන්ම විකල්පයකි.

මුලාශ්‍ර:

• MySQL දිනය / වේලාව දත්ත වර්ග යොමුව
• MySQL ආචයන අවශ්‍යතා යොමුව

MySQL සහ PHP සමඟ වැඩ කිරීමේදී මම සෑම විටම යුනික්ස් කාලරාමුව භාවිතා කරමි. PHP හි පෙරනිමි දිනය ක්‍රමය මෙයට ප්‍රධාන හේතුව පරාමිතිය ලෙස කාලරාමුව භාවිතා කරයි, එබැවින් විග්‍රහ කිරීම අවශ්‍ය නොවේ.

PHP හි වර්තමාන යුනික්ස් කාලරාමුව ලබා ගැනීම සඳහා, කරන්න time();
සහ MySQL කරන්න SELECT UNIX_TIMESTAMP();.

MySQL හි සඳහන් කිරීම වටී, ඔබේ වගු තීරු නිර්මාණය කිරීමේදී පහත දැක්වෙන රේඛා ඔස්සේ යමක් භාවිතා කළ හැකිය:

on update CURRENT_TIMESTAMP

මෙය ඔබ පේළියක් වෙනස් කරන සෑම අවස්ථාවකම වේලාව යාවත්කාලීන කරනු ඇති අතර සමහර විට ගබඩා කළ අවසන් සංස්කරණ තොරතුරු සඳහා ඉතා ප්‍රයෝජනවත් වේ. කෙසේ වෙතත් මෙය ක්‍රියාත්මක වන්නේ කාලරාමුව සමඟ මිස දිවා කාලයේ නොවේ.

මගේ අත්දැකීම් අනුව, ඔබට එක් වරක් පමණක් ඇතුළත් වන දින ක්ෂේත්‍රයක් අවශ්‍ය නම් සහ එම ක්ෂේත්‍රය පිළිබඳ යාවත්කාලීන කිරීමක් හෝ වෙනත් ක්‍රියාමාර්ගයක් ගැනීමට ඔබට අවශ්‍ය නැතිනම්, දිනය සමඟ යන්න .

උදාහරණයක් ලෙස, ලියාපදිංචි දිනය ක්ෂේත්‍රයක් සහිත userවගුවක් සලකා බලන්න . එම වගුවේ, කිසියම් පරිශීලකයෙකුගේ අවසන් වරට ලොග් වූ වේලාව දැන ගැනීමට ඔබට අවශ්‍ය නම්, කාලරාමු වර්ගයේ ක්ෂේත්‍රයක් සමඟ ගොස් ක්ෂේත්‍රය යාවත්කාලීන වේ.user

ඔබ phpMyAdmin වෙතින් වගුව නිර්මාණය කරන්නේ නම්, පේළි යාවත්කාලීන කිරීමක් සිදු වූ විට පෙරනිමි සැකසුම කාලරාමු ක්ෂේත්‍රය යාවත්කාලීන කරනු ඇත . ඔබගේ කාලරාමුව ගොනු කිරීම පේළි යාවත්කාලීන කිරීම් සමඟ යාවත්කාලීන නොවන්නේ නම්, ඔබට පහත සඳහන් විමසුම භාවිතා කර කාලරාමු ක්ෂේත්‍රයක් ස්වයංක්‍රීයව යාවත්කාලීන කර ගත හැකිය.

ALTER TABLE your_table
      MODIFY COLUMN ts_activity TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;

කාලරාමු දත්ත වර්ගය දිනය හා වේලාව ගබඩා කරයි, නමුත් යූටීසී ආකෘතියෙන් මිස දිවා කාලයේ මෙන් වර්තමාන කාල කලාප ආකෘතියෙන් නොවේ. ඔබ දත්ත ලබා ගන්නා විට, කාලරාමුව නැවත එය වත්මන් කාල කලාප වේලාව බවට පරිවර්තනය කරයි.

එබැවින් ඔබ ඇමරිකා එක්සත් ජනපදයේ සිටින අතර ඇමරිකා එක්සත් ජනපදයේ කාල කලාපයක් ඇති සේවාදායකයකුගෙන් දත්ත ලබා ගනී යැයි සිතමු. එවිට ඔබට ඇමරිකා එක්සත් ජනපද කාල කලාපයට අනුව දිනය හා වේලාව ලැබෙනු ඇත. කාලරාමුව දත්ත වර්ග තීරුව සෑම විටම එහි පේළිය යාවත්කාලීන වූ විට ස්වයංක්‍රීයව යාවත්කාලීන වේ. එබැවින් යම් පේළියක් අවසන් වරට යාවත්කාලීන කළ විට එය නිරීක්ෂණය කිරීම ප්‍රයෝජනවත් වේ.

වැඩි විස්තර සඳහා ඔබට බ්ලොග් පෝස්ට් ටයිම්ස්ටැම්ප් එදිරිව දිවා කාලය කියවිය හැකිය .

මම සෑම විටම යුනික්ස් කාලරාමුව භාවිතා කරමි, හුදෙක් දිවා කාලයේ තොරතුරු රාශියක් සමඟ ගනුදෙනු කිරීමේදී, විශේෂයෙන් කාල කලාප සඳහා ගැලපීම් සිදුකරන විට, දින එකතු කිරීම / අඩු කිරීම සහ වෙනත් යනාදිය සමඟ සනීපාරක්ෂාව පවත්වා ගැනීම සඳහා. කාලරාමු සංසන්දනය කිරීමේදී, මෙය කාල කලාපයේ සංකීර්ණ සාධක බැහැර කරන අතර ඔබේ සේවාදායක පාර්ශව සැකසීමේදී (එය යෙදුම් කේතය හෝ දත්ත සමුදා විමසීම් වේවා) සම්පත් ඉතිරි කර ගැනීමට ඉඩ සලසයි, එමඟින් ඔබ සැහැල්ලු බර ගණිතය භාවිතා කරන අතර ඊට වඩා බර දිනය-වේලාව එකතු කිරීම / අඩු කිරීම කාර්යයන්.

සලකා බැලිය යුතු තවත් දෙයක්:

ඔබ යෙදුමක් ගොඩනඟන්නේ නම්, ඔබේ දත්ත සීමාව ඉක්මවා භාවිතා කළ යුතු ආකාරය ඔබ කිසි විටෙකත් නොදනී. තෙවන පාර්ශවීය ඒපීඅයි එකක ඇති අයිතම සමූහයක් සමඟ ඔබේ දත්ත කට්ටලයේ ඇති වාර්තා පොකුරක් සංසන්දනය කර ඒවා කාලානුක්‍රමික පිළිවෙලට තබන්නැයි ඔබ සිතන්නේ නම්, ඔබ සතුටු වනු ඇත ඔබේ පේළි සඳහා යුනික්ස් කාලරාමු. ඔබ MySQL කාලරාමු භාවිතා කිරීමට තීරණය කළත්, යුනික්ස් කාලරාමුව රක්ෂණයක් ලෙස ගබඩා කරන්න.

මගේ නඩුවේදී, මම සෑම දෙයක්ම සඳහා කාල කලාපයක් ලෙස යූටීසී සකසා ඇත: පද්ධතිය, දත්ත සමුදා සේවාදායකය යනාදිය මට හැකි සෑම අවස්ථාවකම. මගේ ගනුදෙනුකරුට වෙනත් කාල කලාපයක් අවශ්‍ය නම්, මම එය යෙදුම මත වින්‍යාස කරමි.

මම සෑම විටම පාහේ දිවා කාල ක්ෂේත්‍රයන්ට වඩා කාලරාමු වලට කැමැත්තක් දක්වන්නෙමි, මන්ද කාලරාමු වල ව්‍යංගයෙන් කාල කලාපය ඇතුළත් වේ. එබැවින්, විවිධ කාල කලාප වලින් පරිශීලකයින්ගෙන් යෙදුම ප්‍රවේශ වන මොහොතේ සිට සහ ඔවුන්ගේ ප්‍රාදේශීය කාල කලාපයේ දිනයන් සහ වේලාවන් දැකීමට ඔබට අවශ්‍ය බැවින්, මෙම ක්ෂේත්‍ර වර්ගය එය දිවා කාල ක්ෂේත්‍රයන්හි දත්ත සුරකිනවාට වඩා එය කිරීමට පහසු කරයි. .

ප්ලස් ලෙස, දත්ත සමුදාය වෙනත් කාල කලාපයක් සහිත පද්ධතියකට සංක්‍රමණය වන විට, මට කාලරාමු භාවිතා කිරීම පිළිබඳ වැඩි විශ්වාසයක් දැනෙනු ඇත. තත්පර දෙකක කාල පරතරයක් අතර වෙනස ගණනය කිරීමේදී හා පැය 1 ක් හෝ ඊට අඩු නිරවද්‍යතාවයක් අවශ්‍ය විටදී ඇතිවිය හැකි ගැටළු නොකියයි.

එබැවින්, සාරාංශගත කිරීම සඳහා, කාලරාමුවෙහි මෙම වාසි මම අගය කරමි:

• ජාත්‍යන්තර (බහු කාල කලාප) යෙදුම්වල භාවිතා කිරීමට සූදානම්
• කාල කලාප අතර පහසුවෙන් සංක්‍රමණය වීම
• වෙනස්කම් ගණනය කිරීම පහසුය (කාලරාමු දෙකම අඩු කරන්න)
• ගිම්හාන කාල පරිච්ඡේදයක් තුළ / පිටත දිනයන් ගැන කරදර නොවන්න

මේ සියලු හේතු නිසා, මම තෝරා ගත හැකි UTC සහ කාලරාමු ක්ෂේත්‍ර තෝරා ගනිමි. මම හිසරදය වළක්වනවා;)

ඔබ මේසයක් මත යාවත්කාලීන ප්‍රකාශයක් කරන විට කාලරාමුව වෙනස් වීම ගැන පරිස්සම් වන්න. ඔබට 'නම' (වර්චාර්), 'වයස' (int), සහ 'දිනය_ එකතු කරන ලද' (කාලරාමුව) යන තීරු සහිත වගුවක් තිබේ නම් ඔබ පහත සඳහන් DML ප්‍රකාශය ක්‍රියාත්මක කරයි

UPDATE table
SET age = 30

ඔබගේ 'දිනය_ එකතු කළ' තීරුවේ සෑම අගයක්ම වත්මන් කාලරාමුව වෙත වෙනස් කරනු ලැබේ.

මෙම ලිපියෙන් ලබාගත් සඳහන:

ප්රධාන වෙනස්කම්:

වාර්තා වල වෙනස්කම් නිරීක්ෂණය කිරීමට TIMESTAMP භාවිතා කරයි, සහ වාර්තාව වෙනස් වූ සෑම අවස්ථාවකම යාවත්කාලීන කරන්න. නිශ්චිත හා ස්ථිතික අගය ගබඩා කිරීම සඳහා භාවිතා කරන DATETIME, එය වාර්තා වල කිසිදු වෙනසක් මගින් බලපෑමට ලක් නොවේ.

TIMESTAMP ද විවිධ කාල කලාප සම්බන්ධ සැකසුම් වලට බලපායි. DATETIME නියතයි.

TIMESTAMP අභ්‍යන්තරව වත්මන් කාල කලාපය UTC ලෙස ගබඩා කිරීම සඳහා පරිවර්තනය කර ඇති අතර නැවත ලබා ගැනීමේදී වත්මන් කාල කලාපයට පරිවර්තනය වේ. DATETIME හට මෙය කළ නොහැක.

TIMESTAMP සහය දක්වන පරාසය: '1970-01-01 00:00:01 ′ UTC සිට' 2038-01-19 03:14:07 ′ UTC DATETIME සහය දක්වන පරාසය: '1000-01-01 00:00:00 ′ සිට' 9999 දක්වා -12-31 23:59:59

+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+
|                                       TIMESTAMP                                       |                                 DATETIME                                 |
+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+
| TIMESTAMP requires 4 bytes.                                                           | DATETIME requires 8 bytes.                                               |
| Timestamp is the number of seconds that have elapsed since January 1, 1970 00:00 UTC. | DATETIME is a text displays 'YYYY-MM-DD HH:MM:SS' format.                |
| TIMESTAMP supported range: ‘1970-01-01 00:00:01′ UTC to ‘2038-01-19 03:14:07′ UTC.    | DATETIME supported range: ‘1000-01-01 00:00:00′ to ‘9999-12-31 23:59:59′ |
| TIMESTAMP during retrieval converted back to the current time zone.                   | DATETIME can not do this.                                                |
| TIMESTAMP is used mostly for metadata i.e. row created/modified and audit purpose.    | DATETIME is used mostly for user-data.                                   |
+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+

ටයිම්ස්ටැම්ප් සහ ඩේටයිම් අතර ඇති තවත් වෙනසක් වන්නේ ටයිම්ස්ටැම්ප් හි ඔබට පෙරනිමි අගය එන්.යූ.එල්.

අනවශ්‍ය ප්‍රේරක භාවිතා නොකර වත්මන් කාලය මත පදනම්ව ස්වයංක්‍රීයව යාවත්කාලීන කිරීමට TIMESTAMP සතු හැකියාව තුළ අසීමිත ප්‍රයෝජනයක් මට හමු විය. TIMESTAMP UTC වුවත් එය කීවාක් මෙන් එය මට පමණි.

එයට විවිධ කාල කලාප හරහා ගමන් කළ හැකිය, එබැවින් ඔබට සාපේක්ෂ වේලාවක් ප්‍රදර්ශනය කිරීමට අවශ්‍ය නම්, UTC වේලාව ඔබට අවශ්‍ය වේ.

ප්රධාන වෙනස වන්නේ

• ටයිම්ස්ටැම්ප් හි INDEX එකක් - ක්‍රියා කරයි
• INDEX හි දිවා කාලය - ක්‍රියා නොකරයි

දිවා කාල සුචිගත කිරීමේ ගැටළු බැලීමට මෙම ලිපිය බලන්න

datetimeකාල කලාප හා සම්බන්ධ බොහෝ ගැටලු සහ දෝෂ වලට මුහුණ දීමෙන් පසු මම මගේ යෙදුම් භාවිතය නතර කළෙමි . IMHO භාවිතය බොහෝ අවස්ථාවන්ට timestampවඩා හොඳයdatetime .

වේලාව කුමක්දැයි ඔබ ඇසූ විට? පිළිතුර '2019-02-05 21:18:30' වැනි දෙයක් ලෙස පැමිණේ, එය සම්පුර්ණ කර නැත, අර්ථ දක්වා නැති පිළිතුරට වෙනත් කොටසක් නොමැති නිසා, කුමන කාල කලාපයේද? වොෂිංටන්? මොස්කව්? බීජිං?

කාල කලාපය නොමැතිව දත්ත වේලාවන් භාවිතා කිරීම යන්නෙන් අදහස් වන්නේ ඔබේ යෙදුම ගනුදෙනු කරන්නේ කාල කලාප 1 ක් පමණක් බවයි, කෙසේ වෙතත් කාලරාමු මඟින් ඔබට ප්‍රතිලාභ ලබා දේ datetime විවිධ කාල කලාපවල එකම නිශ්චිත වේලාවක් පෙන්වීමේ සහ නම්‍යතාවය .

මෙන්න ඔබ භාවිතා කිරීම ගැන පසුතැවෙන datetimeසහ ඔබගේ දත්ත කාලරාමුවල ගබඩා කර තැබීමට ප්‍රාර්ථනා කරන අවස්ථා කිහිපයක් .

1. ඔබේ ගනුදෙනුකරුවන්ගේ සැනසීම සඳහා ගණිතය සිදු නොකර ඔවුන් කැමති කාල කලාප මත පදනම්ව වේලාවන් පෙන්වීමට සහ කාලය ඔවුන්ගේ අර්ථවත් කාල කලාපයට පරිවර්තනය කිරීමට ඔබට අවශ්‍යය. ඔබට අවශ්‍ය වන්නේ කාල කලාපය වෙනස් කිරීම පමණක් වන අතර ඔබගේ සියලුම යෙදුම් කේතය එක හා සමාන වේ. (ඇත්ත වශයෙන්ම ඔබ සෑම විටම යෙදුම ආරම්භයේ කාල කලාපය නිර්වචනය කළ යුතුය, නැතහොත් PHP යෙදුම් සම්බන්ධයෙන් සැකසුම් ඉල්ලන්න)

   SET time_zone = '+2:00';

2. ඔබ රැඳී සිටින රට වෙනස් කළ අතර, දත්ත වෙනත් කාල කලාපයකින් (සත්‍ය දත්ත වෙනස් නොකර) දකින අතරතුර නඩත්තු කිරීමේ ඔබේ වැඩ කටයුතු කරගෙන යන්න.

3. ඔබ ලොව පුරා විවිධ සේවාදායකයින්ගේ දත්ත පිළිගනී, ඒ සෑම කෙනෙකුම ඔහුගේ කාල කලාපයේ කාලය ඇතුල් කරයි.

කෙටියෙන්

datetime = යෙදුම 1 කාල කලාපයට සහය දක්වයි (ඇතුළු කිරීම සහ තේරීම යන දෙකම සඳහා)

timestamp = යෙදුම ඕනෑම කාල කලාපයකට සහය දක්වයි (ඇතුළු කිරීම සහ තේරීම යන දෙකම සඳහා)

මෙම පිළිතුර කාල කලාප සම්බන්ධයෙන් නම්යශීලීභාවය සහ කාලරාමු වල පහසුව පිළිබඳව යම් ඉස්මතු කිරීමක් සඳහා පමණක් වන අතර, එය තීරු ප්‍රමාණය හෝ පරාසය හෝ භාගය වැනි වෙනත් වෙනස්කම් ආවරණය නොකරයි .

සෑම දෙයක්ම එක පොදු අමු ආකෘතියක තබා ගැනීමට සහ PHP කේතයේ හෝ ඔබේ SQL විමසුමේ දත්ත සංයුති කිරීමට මම කාලරාමුව භාවිතා කිරීමට කැමැත්තෙමි. සෑම දෙයක්ම සරල තත්පර කිහිපයක තබා ගැනීම සඳහා ඔබේ කේතයේ ප්‍රයෝජනවත් වන අවස්ථා තිබේ.

A ට TIMESTAMPබයිට් 4 ක් අවශ්‍ය වන අතර a ට DATETIMEබයිට් 8 ක් අවශ්‍ය වේ.

එසේ නොවේ. මෙම DATETIMEසහ TIMESTAMPවර්ග අතිමූලික Generic බලපත්රය යටතේ අවසර ලබා ඇත භාවිතය නඩු සඳහා කැඩිලා. MySQL අනාගතයේදී ඒවා වෙනස් කරනු ඇත. ඔබට BIGINTවෙනත් දෙයක් භාවිතා කිරීමට නිශ්චිත හේතුවක් නොමැති නම් ඔබ යුනික්ස් කාලරාමු භාවිතා කළ යුතුය .

විශේෂ අවස්ථා

ඔබේ තේරීම පහසු වන විශේෂිත අවස්ථා කිහිපයක් මෙන්න, මෙම පිළිතුරේ විශ්ලේෂණය සහ සාමාන්‍ය නිර්දේශය ඔබට අවශ්‍ය නොවේ.

• දිනය පමණි - ඔබ දිනය ගැන පමණක් සැලකිලිමත් වන්නේ නම් (ඊළඟ චන්ද්‍ර අලුත් අවුරුද්දේ දිනය, 2020-02-25 වැනි) සහ එම දිනය අදාළ වන කාල කලාපය පිළිබඳව ඔබට පැහැදිලි අවබෝධයක් ඇත (නැතහොත් එය ගණන් නොගන්න. චන්ද්ර අලුත් අවුරුද්දේ) ඉන්පසු DATEතීරු වර්ගය භාවිතා කරන්න.

• ඇතුළත් කිරීමේ වේලාවන් සටහන් කරන්න - ඔබ ඔබේ දත්ත ගබඩාවේ පේළි සඳහා ඇතුළත් කිරීමේ දිනයන් / වේලාවන් සටහන් කරන්නේ නම් සහ ඉදිරි වසර 19 තුළ ඔබේ යෙදුම බිඳී යනු ඇතැයි ඔබ නොසිතන්නේ නම්, ඉදිරියට ගොස් TIMESTAMPපෙරනිමි අගයක් භාවිතා කරන්න CURRENT_TIMESTAMP().

TIMESTAMPකැඩී ඇත්තේ ඇයි ?

TIMESTAMPවර්ගය UTC කාල කලාපයේ තැටියේ ගබඩා කර ඇත. මෙයින් අදහස් කරන්නේ ඔබ ඔබේ සේවාදායකය භෞතිකව ගෙන ගියහොත් එය කැඩී නොයන බවයි. ඒක හොඳයි. නමුත් දැනට අර්ථ දක්වා ඇති පරිදි කාලරාමු 2038 වර්ෂයේදී සම්පූර්ණයෙන්ම වැඩ කිරීම නවත්වනු ඇත.

සෑම අවස්ථාවකදීම ඔබ INSERT INTOහෝ SELECT FROMඅTIMESTAMP තීරුව, ඔබේ සේවාදායක / මෘදුකාංගය භෞතික පිහිටීම (එනම් වේලා කලාපය වින්යාසය) සැලකිල්ලට ගෙන ඇත. ඔබ ඔබේ යෙදුම් සේවාදායකය ගෙන යන්නේ නම් ඔබගේ දිනයන් කැඩී යයි.

ඇයි DATETIMEකැඩී ?

ඒ DATETIMEගබඩා වන DATEහාTIME එකම තීරුවක . කාල කලාපය වටහාගෙන, කාල කලාපය කොතැනකවත් ගබඩා කර නොමැති නම් මේ දෙකටම අර්ථයක් නැත. කාල කලාපය දත්ත සමඟ නොවැලැක්විය හැකි ලෙස සම්බන්ධ වී ඇති නිසා ඔබ අපේක්ෂිත කාල කලාපය තීරුවේ විවරණයක් ලෙස තැබිය යුතුය. එබැවින් ස්වල්ප දෙනෙක් තීරු අදහස් භාවිතා කරති, එබැවින් මෙය සිදුවීමට බලා සිටීම වැරදිය. මට ඇරිසෝනා වෙතින් සේවාදායකයක් උරුම විය, එබැවින් මට සෑම විටම ඇරිසෝනා වේලාවෙන් සියලුම කාලරාමු වෙනත් කාලයකට පරිවර්තනය කළ යුතුය.

DATETIMEනිවැරදි වන එකම තත්වය මෙම වාක්‍යය සම්පූර්ණ කිරීමයි:

ඔබේ වසර 2020 සූර්ය නව වසර ආරම්භ වන්නේ හරියටම ය DATETIME("2020-01-01 00:00:00").

DATETIMES සඳහා වෙනත් හොඳ භාවිතයක් නොමැත . සමහර විට ඔබ ඩෙලවෙයාර්හි නගර රජයක් සඳහා වෙබ් සේවාදායකයක් ගැන සිතනු ඇත. නිසැකවම මෙම සේවාදායකයේ කාල කලාපය සහ මෙම සේවාදායකයට ප්‍රවේශ වන සියලුම පුද්ගලයින් නැගෙනහිර කාල කලාපය සමඟ ඩෙලවෙයාර් හි සිටින බව ඇඟවිය හැකිය, නේද? වැරදි! මෙම සහස්‍රයේ දී, අපි සියල්ලෝම සේවාදායකයන් "වලාකුළෙහි" පවතින බව සිතමු. එබැවින් කිසියම් නිශ්චිත කාල කලාපයක් තුළ ඔබේ සේවාදායකය ගැන සිතීම සැමවිටම වැරදිය, මන්ද ඔබේ සේවාදායකය යම් දිනෙක ගෙන යනු ඇත.

භාවිතා කරන්නේ කෙසේද BIGINT?

අර්ථ දක්වන්න:

CREATE TEMPORARY TABLE good_times (
    a_time BIGINT
)

නිශ්චිත අගයක් ඇතුළු කරන්න:

INSERT INTO good_times VALUES (
    UNIX_TIMESTAMP(CONVERT_TZ("2014-12-03 12:24:54", '+00:00', @@global.time_zone))
);

හෝ ඇත්ත වශයෙන්ම මෙය ඔබගේ යෙදුමෙන් වඩා හොඳය, වැනි:

$statement = $myDB->prepare('INSERT INTO good_times VALUES (?)');
$statement->execute([$someTime->getTimestamp()]);

තෝරන්න:

SELECT a_time FROM good_times;

සාපේක්ෂ වේලාවන් පෙරීම සඳහා ශිල්පීය ක්‍රම තිබේ (පසුගිය දින 30 තුළ තනතුරු තෝරන්න, ලියාපදිංචි වී මිනිත්තු 10 ක් ඇතුළත මිලදී ගත් පරිශීලකයින් සොයා ගන්න) මෙහි විෂය පථයෙන් ඔබ්බට.