باگ سال ۲۰۰۰ یا Y2K اصطلاحی بود که در آستانه‌ی قرن بیست‌ویکم متولد شد و توجه جهانیان را به خود جلب کرد.
بیش از دو دهه پیش، زمانی‌که جهان برای قرنی جدید آماده می‌شد، اصطلاح و عبارتی به‌نام باگ سال ۲۰۰۰ یا Y2K مطرح شد که بسیاری از کارشناسان دنیای کامپیوتر را وحشت‌زده کرد. در آن دوره، کامپیوترهای شخصی در اوج قرار داشتند و تقریبا همهی مردم جهان دیگر با بازیگران جدید زندگی خود آشنا بودند. این دستگاه‌ها به‌مرور به وسایلی الزامی در زندگی و کار همهی مردم تبدیل شدند؛ اما احتمال بحرانی بزرگ برای همهی آن‌ها پیش‌بینی می‌شد. در آستانه‌ی قرن بیست‌ویکم، دولت‌ها و سازمان‌های گوناگون نظامی و ملی در سرتاسر جهان، میلیاردها دلار هزینه کردند تا از باگ احتمالی Y2K جلوگیری کنند. به‌هرحال، آن دوره تمام شد و تقریبا هیچ مشکل بزرگی برای دنیای کامپیوتر به‌همراه نداشت. امروز و پس از گذشت دو دهه، این سؤال ایجاد می‌شود که آیا واقعا با بحران و مسئله‌ی بزرگی روبه‌رو بودیم؟
در دهه‌های ۱۹۵۰ و ۱۹۶۰، نمایش سال‌ها با دو رقم روندی مرسوم شد. تنها دلیل استفاده از این رسم جدید، حفظ فضای بیشتر بود. به‌هرحال، اولین کامپیوترهای تاریخ حافظه‌های محدودی داشتند. حافظه‌ی رم کامپیوتر در میانه‌ی قرن بیستم نسبت بسیار کوچکی از ظرفیت حافظه‌ی رم در کامپیوتر مدرن امروزی داشت؛ درنتیجه برنامه‌های کامپیوتری باید تاحدممکن کوچک و فشرده و پربازده می‌شدند. برنامه‌ها از کارت‌های پانچی خوانده می‌شدند که عرض محدودی داشتند و عموما به ۸۰ ستون پانچ محدود بودند.
برنامه‌نویسان و دانشمندان علوم کامپیوتر در سال‌های شکوفایی صنعت، به‌دنبال هر راه ممکنی بودند تا فضای بیشتری در سیستم‌ها و برنامه‌ها ذخیره کنند. اولین بخشی که به ذهن آن‌ها رسید، روش نوشتار تاریخ بود. مهندسان تصمیم گرفتند سال‌ها را به‌جای نمایش با چهار رقم (مثلا ۱۹۵۴) به‌صورت دو رقم (۵۴) نمایش دهند. نرم‌افزارها نیز به‌گونه‌ای طراحی شده بودند که همهی سال‌ها را سال‌های قرن بیستم می‌دانستند؛ درنتیجه هرجا عددی دورقمی به‌عنوان سال می‌دیدند، آن را متعلق به قرن بیستم تفسیر می‌کردند.
سختافزارهای کامپیوتری در دهه‌های بعد پیشرفت کردند. افزایش قدرت و سرعت پردازنده‌ها و حافظه‌ی رم بیشتر برای کامپیوترها و جایگزینی نوارها و کارت‌های پانچ با ترمینال‌ها، نشان‌دهنده‌ی پوست‌اندازی دنیای پردازش بود. سختافزارهای مغناطیسی مانند نوارها و هارد درایوها برای ذخیره‌سازی داده و برنامه‌ها استفاده شدند. دنیای کامپیوتر با سرعت عجیبی رشد کرده بود و نیاز به ذخیره‌سازی داده‌های بیشتر و متنوع‌تر، مهندسان را به توسعه‌ی سختافزارهای مدرن‌تر و سریع‌تر مجبور میکرد.
با وجود پیشرفت سریع فناوری کامپیوتر، عملکرد دپارتمان‌ها و سازمان‌هایی که از آن‌ها استفاده می‌کردند، ثابت مانده بود. حتی در برخی موارد که نرم‌افزارها ارتقا پیدا می‌کردند، فرمت داده‌ها ثابت می‌ماند؛ درنتیجه نرم‌افزارها در سال‌های بعدی هم با همان روند دو رقم برای نمایش سال پیش رفتند. به‌هرحال با افزایش داده‌های جمع‌آوری‌شده در سرتاسر صنعت، مشکلات بیشتر شد. داده‌ها در برخی موارد بسیار حجیم و بزرگ می‌شدند و فرمت داده‌ها نیز به مفهومی مقدس برای برنامه‌نویسان تبدیل شده بود. همهی نرم‌افزارها از داده‌ها پیروی می‌کردند و در نگارش داده‌ها نیز استفاده از دو رقم برای نمایش سال تقریبا تثبیت شده بود. در بخش دیگری از صنعت نیز، شاهد ادامه‌دار بودن مشکل ظرفیت حافظه بودیم. به‌عنوان مثال، سیستمهای یکپارچه (امبدد) مانند فرمور روترها و فایروال‌ها هنوز محدودیت‌های فضا داشتند.
به‌جز کامپیوترهای شخصی، کاربردهای صنعتی بسیاری برای سختافزارهای پردازشی متولد شده بود. کنترلرهای منطقی برنامه‌ریزی‌شدنی (PLC، ماشین‌های ساخت‌وتولید خودکار، خطوط تولید رباتیک و سیستمهای کنترل صنعتی) همگی به ساختاری از داده عادت کرده بودند که تاحدممکن، کوچک و فشرده شده بود. درنهایت، کوچک‌کردن فرمت تاریخ از چهار رقم به دو رقم، به‌هرحال فضای موردنیاز را برای ذخیره‌ی آن بخش از داده نصف میکرد؛ اما همین روند در پایان قرن بحران‌هایی ایجاد کرد.
نکته‌ی ساده و واضح این است که وقتی از دو رقم برای نمایش سال‌ها استفاده کنید، نمی‌توان تفاوت سال‌ها در قرن‌های متفاوت را درک کرد. همان‌طورکه گفته شد، نرم‌افزارها به‌گونه‌ای طراحی شده بودند که همهی سال‌ها را در قرن بیستم تصور می‌کردند. چنین رویکردی با ورود به قرن جدید مشکلاتی ایجاد میکرد. سال ۲۰۰۰، در تاریخ‌های کامپیوتری «۰۰» خوانده می‌شد؛ درنتیجه برنامه‌ها سال جدید را ۱۹۰۰ تفسیر می‌کردند و سال‌های بعد مثلا ۲۰۱۵، با ۱۹۱۵ اشتباه گرفته می‌شد و روند مذکور ادامه پیدا میکرد.
با رسیدن به ساعت ۲۴ روز ۳۱ دسامبر سال ۱۹۹۹، همهی کامپیوترها و تمامی دستگاه‌هایی که از ریزپردازنده و نرم‌افزارهای امبدد بهره می‌بردند (و تاریخ را با دو رقم ذخیره می‌کردند)، با مشکل جدیدی روبه‌رو می‌شدند. البته احتمالا نرم‌افزارها تاریخ جدید را می‌پذیرفتند و به کار خود ادامه می‌دادند؛ اما درنهایت خروجی نامناسب تحویل می‌دادند. احتمال دیگر این بود که کامپیوتر پس از نمایش پیغام خطا، به کار ادامه دهد یا در بدترین حالت عملیاتش متوقف شود.
چالش تاریخ با تغییر قرن به کامپیوترهای مین‌فریم، مینی‌کامپیوتر، شبکه و کامپیوترهای رومیزی محدود نبود و ریزپردازنده‌ها در بسیاری از ساختارهای فنی استفاده می‌شدند. هواپیماها، کارخانه‌ها، مراکز انتقال نیرو، سیستمهای کنترل موشک و ماهواره‌های ارتباطی، تجهیزات و زیرساخت‌هایی حیاتی بودند که از این قطعات پردازشی بهره می‌بردند. در آستانه‌ی قرن بیست‌ویکم، تقریبا کل جهان در ساختاری خودکار یا الکترونیک یا پیکربندی‌پذیر قرار داشت که به‌کمک کدهای کامپیوتری کار میکرد. درنتیجه مقیاس نمایش تاریخ، جهانی و به‌بیان‌بهتر، بحرانی بود.
اگر همهی کامپیوترهای ریزودرشت جهان در یک لحظه از تاریخ ۱۹۹۹ به ۱۹۰۰ تغییر می‌کردند، چه اتفاقی رخ می‌داد؟ در میان چالش و نگرانی مهندسان، قطعا گروهی به تئوری توطئه هم علاقه‌مند بودند که پایان جهان یا فروپاشی جوامع را پیش‌بینی می‌کردند. حتی در روندی مشابه با بحران کنونی همه‌گیری ویروس کرونا، بسیاری از مردم دست به انبارکردن کالاهای اساسی زدند. برخی دیگر مسئله را شوخی و فریب رسانه‌ای می‌دانستند؛ اما به‌هرحال خبر مهم و تاریخ‌سازی در کل جهان جریان پیدا کرده بود. همان‌طورکه گفته شد، مشکل یا باگ مذکور به‌نام باگ سال ۲۰۰۰ یا باگ Y2K یا باگ هزاره شناخته می‌شد.
مسئله‌ی دیگر سال ۲۰۰۰ در تقویم‌های کامپیوتری، کبیسه‌بودن آن بود. ساختار سال‌های کبیسه این‌گونه محاسبه شده بود که اگر سالی تقسیم‌پذیر بر عدد چهار باشد، کبیسه محسوب می‌شود و ۳۶۶ روز دارد. درحالی‌که سال‌های تقسیم‌پذیر بر ۱۰۰، در محاسبه‌های کامپیوتری غیرکبیسه بودند. البته این محاسبه قانون دیگری هم داشت که در اکثر برنامه‌های کامپیوتری پیاده نشده بود. سال‌های تقسیم‌پذیر به ۴۰۰، مانند سال ۲۰۰۰ هم کبیسه هستند. همین لحاظ‌نکردن قانون آخر باعث می‌شد کامپیوترها سال ۲۰۰۰ را کبیسه حساب نکنند و در محاسبه‌ی تعداد روزهای آن با مشکل روبه‌رو شوند. درنهایت، چگونگی پردازش و مدیریت تاریخ ۲۹ فوریه‌ی ۲۰۰۰ هم در آن‌ها مشخص نبود.
بحران باگ سال ۲۰۰۰ به‌حدی بود که حتی رئیس‌جمهور وقت ایالات متحده، بیل کلینتون، در یکی از سخنرانی‌های خود به آن اشاره کرد. او گفته بود: «تمامی دولت‌های محلی و ملی و کسب‌وکارها اعم از کوچک و بزرگ باید تلاش کنند باگ کامپیوتری Y2K به آخرین دردسر قرن بیستم تبدیل شود، نه اینکه اولین بحران قرن بیست‌ویکم باشد». کلینتون همچنین برنامه‌ای کشوری برای مدیریت چالش تصویب کرد.
دولت‌ها و سازمان‌های گوناگونی در سرتاسر جهان از سال‌ها پیش از ۱۹۹۹ مشغول کار روی توسعه‌ی راه‌حلی برای حل بحران Y2K بودند. راه‌حل اولیه‌ای که به ذهن همه می‌رسید، اضافه‌کردن فیلد تاریخ یا سال برای ذخیره‌ی دو رقم بیشتر بود. سپس باید به تمامی مقادیر تاریخ در برنامه‌ها، عدد ۱۹۰۰ را اضافه می‌کردند. با این راهکار، ظاهرا مشکل سریعا حل می‌شد. همهی تاریخ‌های قدیمی با ساختار صحیح نمایش داده و داده‌های جدید نیز به‌خوبی ذخیره می‌شدند.
متأسفانه بهدلیل هزینه‌های زیاد و ریسک فراوان از‌دست‌رفتن داده و حجم عظیم کارها این راهکار در بسیاری از موارد امکان پیاده‌سازی نداشت. البته در مواردی که راهکار پیاده‌سازی می‌شد، سیستم‌ها ازلحاظ فرمت تاریخی تا سال ۹۹۹۹ تضمین می‌شدند.
حتی اگر راهکار بالا اجرا می‌شد، تنها داده‌ها اصلاح می‌شدند و هنوز مرحله‌ی مهمی پیش روی مهندسان و متخصصان بود: نرم‌افزارها نیز باید تغییر حالت می‌دادند تا سال‌هایی با ساختار چهار رقم را مدیریت و محاسبه و ذخیره کنند و نمایش دهند. دراین‌میان، راهکارهایی خلاقانه هم متولد شد که نیاز به افزایش حافظه ذخیره‌سازی برای ذخیره‌ی دادهی سال را از بین می‌برد. می‌دانیم مقادیر متغیر ماه هیچ‌گاه از عدد ۱۲ بیشتر نمی‌شود؛ درحالی‌که فیلد دورقمی آن‌ها توانایی ذخیره‌ی مقادیر تا ۹۹ را دارد. درنتیجه شاید بتوان با کمی محاسبه، از فضای اضافه بهره برد. راهکار زیر به‌عنوان یکی از روش‌های خلاقانه پیشنهاد شد.
توضیح اولیه‌ی راهکار بالا هم نشان می‌دهد مهندسان برای مدیریت ساختار جدید تاریخه‌ها، باید داده‌ها را رمزنگاری و رمزگشایی می‌کردند. منطق روش‌های تأیید داده هم باید تغییر میکرد تا مقادیری عجیب همچون عدد ۴۴ برای نمایش ماه را درک و تفسیر کند. مثال‌های دیگر و راهکارهای خلاقانه‌ی متعدد، به‌نوعی همین ساختار را دنبال می‌کردند. رمزنگاری تاریخ‌ها به‌صورت داده‌های ۱۴ بیتی و اعداد باینتری و ذخیره‌ی نمایش عدد صحیح آن‌ها در فیلد تاریخ راهکار دیگری بود که در سطح بیتی اجرا می‌شد.
سیستم دیگری هم برای نمایش تاریخ پیشنهاد شد که ماه‌ها را به‌صورت کلی از داده‌ها حذف میکرد. این سیستم از همان فیلد ۶ رقمی برای نمایش تاریخ استفاده میکرد؛ اما به‌جای نمایش داده به‌صورت MMDDYY، ساختاری DDDCYY را پیشنهاد داد. در این سیستم، DDD برای نشان‌دادن روز سال (از ۱ تا ۳۶۵ یا ۳۶۶ برای سال کبیسه) و C به‌عنوان نمادی برای نشان‌دادن قرن و YY برای نشان‌دادن سال استفاده می‌شد.
برخی راهکارها نیز به‌صورت ساده تنها سعی می‌کردند محدودیت را دور بزنند. به‌عنوان مثال، در ساختاری پیشنهاد شد یک سال را به‌عنوان سال چرخش قرن مشخص کنند؛ مثلا اگر تمامی داده‌های سازمان متعلق به پس از سال ۱۹۲۰ بود، آن سال به‌عنوان سال چرخش انتخاب می‌شد. درنتیجه در تمامی تاریخ‌ها، اعداد ۰۰ تا ۲۰ نشان‌دهنده‌ی سال‌های ۲۰۰۰ تا ۲۰۲۰ می‌شد و اعداد ۲۱ تا ۹۹ نیز سال‌های ۱۹۲۱ تا ۱۹۹۹ را نمایش می‌داد. البته این راهکارها همگی کوتاه‌مدت بودند و کمی زمان برای توسعه‌ی راهکار نهایی دراختیار متخصصان قرار می‌دادند.
حل چالش تاریخ در سیستمهای داخلی سازمان‌ها به‌اندازه‌ی کافی مشکل‌ساز بود. حال چالش رفع مشکل کدهای نرم‌افزاری و توزیع آن به تمامی دستگاه‌های مشتریان را هم به آن اضافه کنید. به‌علاوه، ابزارهای توسعه‌ی نرم‌افزاری مانند کتابخانه‌های نرم‌افزاری هم به‌اندازه‌ی کافی مشکل ایجاد می‌کردند. به‌هرحال بحران‌های متعددی پیش‌بینی می‌شد که از نرم‌افزارهای کوچک و خانگی تا سیستمهای توسعه‌یافته‌ی اشتراکی و بسیاری سرویس‌های مشابه را درمعرض خطر قرار می‌داد.
کسب‌وکارها پس از مدتی خود را در میانه‌ی انبوهی از نامه‌ها و کاغذبازی‌های اداری دیدند. شرکت‌ها به‌دنبال تأییدیه‌ای از شرکت‌های نرم‌افزاری و شرکای توسعه‌ای خود بودند تا ضمانت سازگاری برنامه را دریافت کنند. آن‌ها حتی از شرکت‌های نرم‌افزاری درخواست می‌کردند برنامه‌ی آماده‌سازی خود برای Y2K را منتشر و اثبات کنند. توسعه‌دهندگان روز‌به‌روز با فشار بیشتری روبه‌رو می‌شدند و حتی باید روند بازبینی کدها و توسعه‌ی سازگاری با چالش قرن جدید را هم دراختیار مشتریان قرار می‌دادند. درنهایت، مشتریان به‌دنبال این بودند که اگر با ورود به قرن بیست‌ویکم مشکلی برای نرم‌افزارها ایجاد شد، شرکت توسعه‌دهنده مسئولیت آن را قبول کند.
بسیاری از شرکت‌های توسعه‌دهنده‌ی نرم‌افزار با سازمان‌های بزرگی همکاری می‌کردند که هرکدام مشتریان بی‌شماری در سرتاسر جهان داشتند. آخرین روز سال ۱۹۹۹ برای همهی آن‌ها حیاتی بود. میلیون‌ها مشتری در سرتاسر جهان منتظر تأییدیه و ضمانت از شرکت اصلی خدمات‌دهنده بودند و آن‌ها هم به شرکت توسعه‌دهنده‌ی نرم‌افزار فشار وارد می‌کردند. حتی اگر مهندسان راهی برای حل مشکل هم پیدا می‌کردند، اثبات راه‌حل به مشتریان به هزینه و زمان زیادی نیاز داشت.
تخمین‌های جهانی شرکت گارتنر می‌گوید حل بحران Y2K هزینه‌ای بالغ بر ۳۰۰ تا ۶۰۰ میلیارد دلار در جهان به‌همراه داشت و برخی تخمین‌های دیگر هزینه‌ها را تا ۸۲۵ میلیارد دلار هم گزارش می‌دهند. تنها در ایالات متحده، ۱۰۰ میلیارد دلار برای مدیریت چالش احتمالی هزینه شد و محاسبه‌های آماری نشان می‌دهد هزاران نفر ساعت برای حل باگ Y2K هزینه شد.
درنهایت، مؤسسه‌ی استاندارد بریتانیا (BSI) در سال ۱۹۹۷ استانداردی برای تأیید سازگاری برنامه‌ها با Y2K منتشر کرد که شامل چهار قانون پیش‌نیاز می‌شد:
جان کاسکینن، رئیس هیئت مسئول آمریکایی که رئیس‌جمهور برای مدیریت Y2K تشکیل داده بود، در شب سال نو ۲۰۰۰ در هواپیما در حال پرواز بود. او به‌نوعی تصمیم گرفته بود به همه نشان دهد به فعالیت‌های هزینه‌بر و چندساله برای مدیریت و حل باگ سال ۲۰۰۰ اعتقاد دارد و درنهایت، هواپیمای وی به سلامت به زمین نشست.
افراد عادی که در پشت‌صحنه‌ی باگ Y2K نبودند، امروز که به گذشته نگاه می‌کنند، باگ مذکور را بیشتر هیاهوی رسانه‌ای می‌دانند. آن‌ها شاید با خود می‌گویند متخصصان و رسانه‌ها بیش‌از‌حد مشکل Y2K را بزرگ جلوه داده‌اند. به‌هرحال با ورود به قرن بیست‌ویکم، مشکل خاصی به‌وجود نیامد. به‌راستی این همه نگرانی برای چه بود؟
تصور کنید سد بزرگی در دریاچه‌ای ساخته شده است. در پایین دریاچه، روستایی قرار دارد. مقام‌های مسئول می‌گویند تَرَکی روی سد مشاهده کرده‌اند و ساختمان آن بیش از یک سال دوام نخواهد آورد. برنامه‌ی مقاوم‌سازی اجرا می‌شود تا ساختمان سد تقویت شود. درنهایت، کار ساخت‌و‌ساز به‌پایان می‌رسد و با گذشت یک سال هم بحرانی برای اهالی دهکده رخ نمی‌دهد. دراین‌میان، برخی از ساکنان با خود تصور می‌کنند نگرانی‌شان بی‌دلیل بوده است. درواقع، آن‌ها تمامی فعالیت‌های شناسایی و مدیریت و رفع بحران را نادیده گرفته‌اند.
پیتر د جگر از نگاه بسیاری به‌عنوان قهرمان Y2K شناخته می‌شود. او در سال ۱۹۹۳ با مقاله‌ای در مجله‌ی Computerworld، چالش Y2K را کاملا شرح و به‌نوعی آگاهی عمومی را درباره‌ی آن افزایش داد. او از آن زمان فعالیت‌های جدی و کمپین‌های متعددی برگزار کرد تا این چالش اهمیت پیدا کند. پیتر هم در ساعت ۲۴ و زمان ورود به قرن جدید، در هواپیمایی از شیکاگو به لندن پرواز میکرد و هواپیمای او هم به سلامت به زمین نشست.
با اینکه عموم جامعه در دهه‌ی پایانی قرن بیستم متوجه چالش Y2K شده بود، مهندسانی از میانه‌ی قرن بیستم آن را پیش‌بینی کرده بودند. باب بمر، برنامه‌نویسی بود که در سال ۱۹۵۸ در پروژه‌ای نرم‌افزاری متوجه این باگ شد. او دو دهه تلاش کرد تا انواع برنامه‌نویسان، شرکت IBM، دولت ایالات متحده و سازمان استاندارد ISO را مطلع کند و به آن‌ها هشدار دهد. از دستاوردهای تلاش او می‌توان به تغییر استاندارد برنامه‌نویسی کوبول اشاره کرد که استفاده از چهار رقم را برای نمایش سال ممکن میکرد.
با وجود تلاش‌های همه‌جانبه و هزینه‌های سرسام‌آوری که برای مدیریت باگ Y2K صرف شد، چند حادثه در نقاط گوناگون جهان رخ داد. برخی از آن‌ها بسیار بااهمیت بودند و تا حد قطع‌شدن شبکه‌ی جهانی پیش می‌رفتند. البته رخدادهایی وحشتناکی همچون سقوط هواپیماها یا شلیک خودکار موشک‌های هسته‌ای پیش نیامد؛ رخدادهایی که عاشقان تئوری‌های آخرالزمانی پیش‌بینی کرده بودند. البته در همان تاریخ، سه موشک از روسیه به چچن شلیک شد که نگرانی و ترس آمریکایی‌ها را به‌همراه داشت. البته موشک‌ها با دستور مستقیم انسانی شلیک شدند و حاصل شدت‌گرفتن درگیری بین روسیه و گروه‌های چچنی بودند.
حوادث زیر، رخدادهایی بودند که با ورود به قرن بیست‌ویکم و بر اثر باگ Y2K رخ دادند:
باگ Y2K مرتبط با تاریخ در تاریخچه‌ی دنیای فناوری تنها نبوده است؛ زیرا در سال‌های پیش از ۲۰۰۰ و پس‌از‌آن نیز، شاهد باگ‌های مشابهی بوده و خواهیم بود که درادامه به آن‌ها اشاره می‌کنیم.
اکنون و در سال ۲۰۲۰، نگاهی به داستان باگ Y2K و تلاش‌ها و هزینه‌هایی که برای حل آن صرف شد، ما را با تاریخچه‌ای از اهمیت شناسایی سریع بحران‌ها و تلاش برای رفع آن‌ها روبه‌رو می‌کند؛ تلاش‌هایی که با وجود تحمیل هزینه‌های سنگین، به شکل‌گیری راهکارهایی منجر شدند که مانع از بحران‌های جدی بودند. همان‌طورکه گفته شد، اکثر کاربران عادی تجربه‌ی خاصی از ورود به قرن بیست‌ویکم در کامپیوترهای خود نداشتند و درمقابل، تلاش و هزینه‌های متخصصان در پشت‌صحنه، از چالشی بزرگ در دنیای وابسته به کامپیوترها جلوگیری کرد.
راهکاری که در این مطلب به‌عنوان راهکار سال‌های چرخشی بیان شد، چند دهه زمان برای متخصصان خرید تا Y2K را کاملا رفع کنند. هنوز برخی از سیستمهای کامپیوتری در جهان هستند که از آن راهکار استفاده می‌کنند و اختلال در چنین سرویس‌هایی هنوز در برخی اخبار و گزارش‌ها دیده می‌شود. به‌عنوان مثال، برخی دستگاه‌های پارکومتر در نیویورک در ابتدای سال جاری دچار مشکل شدند؛ چون به محدودیت حداکثری سال چرخی خود رسیده بودند و بهدلیل همین اختلال، ۱،۴۰۰ دستگاه تک‌به‌تک بازبینی شدند.
در آیدت،
فایل‌های
خود را به فروش بگذارید و یا
مقالات‌تان
را منتشر کنید👋
پاسخ ها