פעם החזרתי ללקוח $9 בגלל עמוד גדר. ל-SaaS שבניתי היה ניסיון של 14 יום, וקוד היחס שלי חישב את "ימים בשימוש" כ endDate - startDate באלפיות שניות, חלקי 86,400,000, מעוגל התחל משפט ב-11 בערב ב-1, המר ב-1 בבוקר ב-15, והמתמטיקה אמרה 14 ימים - אבל הלקוח 's מודל מנטלי אמר " נרשמתי ב-1, that's יום ראשון," מה שהופך את היום ה-15 לחמישה עשר. האם הניסיון היה 14 ימים או 14 לילות? הקוד שלי ודף התמחור שלי לא הסכימו זה עם זה, והלקוח שם לב לפני ששמתי לב.
That's העניין לגבי אריתמטיקה של תאריכים: החיסור הוא טריוויאלי וה- הגדרה האם המקום שבו הכל משתבש. ספירה כוללת או בלעדית. האם "a month" מ-31 בינואר הוא 28 בפברואר, 2 במרץ או 3 במרץ. האם "day" הוא 24 שעות כאשר שעון הקיץ הופך יום אחד בשנה ל-23 שעות ועוד 25. כל אחד מאלה נשך אותי לפחות פעם אחת, ו-I' שולחים יישומי Laravel ו-React כבר למעלה מעשור.
א מחשבון הפרש תאריכים קיים כדי לענות על השאלה במדויק כדי שתוכל לבדוק את ההנחות שלך - ואת הקוד שלך - מול תוצאה ידועה-נכונה. one on Toolz.dev מחשב את הפער בין כל שני תאריכים בימים, שבועות, חודשים ושנים, כולו בדפדפן שלך.I use it constantly: verifying invoice periods, checking contract durations, setting "how many days until launch" vidences in Slack with a link במקום a vargument.
מדריך זה מכסה כיצד להשתמש בו, ובאופן שימושי יותר - חמש הדרכים שבהן מתמטיקה תאריך משקרת לך בשקט, כך שאתה מזהה אותן בקוד שלך.
TL;DR: בחר שני דייטים ב מחשבון הפרש תאריכים Toolz.dev ולקבל את הפער המדויק בימים, שבועות, חודשים, ושנים - מיידי, חינם, צד הלקוח שלוש המלכודות לבדוק בכל פעם: כולל לעומת ספירה בלעדית (האם תאריך הסיום נספר?), חשבון חודש (חודשים יש 28–31 ימים, אז "1 חודש מאוחר יותר" הוא מעורפל), ואזורי זמן (תאריך ללא אזור זמן הוא רגע שונה בכל אזור - להמיר חותמות זמן תחילה עם ה ממיר חותמת זמן). עבור מרווחים חוזרים ולא פערים חד פעמיים, זה ' הוא עבודה עבור מנתח Cron.
תכונות מפתח
ספירת ימים מדויקת (ללא מוקשים DST)
הפלט הבסיסי: מספר הימים המדויק בין שני תאריכים לוח שנה. הנאיבי (b - a) / 86400000 you' ימצא באלף בסיסי קוד של JavaScript הפסקות בכל פעם שמעבר חוסך אור יום יושב בין התאריכים בזמן מקומי, ומפיק תוצאות כמו 89.958333 ימים שלאחר מכן מתעגלים לאיזה כיוון שגוי. מחשבון זה עוקף את כל מחלקת הבאג על ידי ניתוח שני התאריכים כ-UTC לפני שהוא עושה חשבון כלשהו - UTC אף פעם לא קופץ קדימה או נופל אחורה, כך שיום תמיד יש בדיוק 86,400,000 מילישניות והספירה יוצאת נקייה. פירוט השנים/חודשים/ימים, בינתיים, מחושב עם מתמטיקה אמיתית של לוח שנה (התקדם חודשים שלמים, ואז ספר את הימים שנותרו), לא על ידי חלוקה בחודש ממוצע. כשהקוד שלך אומר 90 והמחשבון אומר 89, האמן למחשבון ולך למצוא את גבול ה-DST בנתוני הזמן המקומי שלך.
מספר יחידות בבת אחת
אותו פער המתבטא כימים, שבועות, חודשים ושנים - בו זמנית. זה שימושי יותר ממה שזה נשמע, כי תחומים שונים מדברים ביחידות שונות: חוזים משפטיים מדברים בחודשים, שיחות תכנון ספרינט בשבועות, שיחות חיוב בימים, שיחות משאבי אנוש בשנות שירות הפער בין ה-15 במרץ ל-15 בספטמבר הוא 184 ימים, 26 שבועות ו-2 ימים, או בדיוק 6 חודשים, ואיזה מספר אתה צריך תלוי לחלוטין במי 's שואל. העובדה שכולם בתצוגה אחת פירושה שאתה מפסיק לעשות את "184 חלקי 7 זה... 26 ו-change" חשבון בראש שלך, שזה בדיוק החשבון שאנשים טועים.
סכומים בלעדיים פלוס ימי עסקים כוללניים
בעיית עמוד הגדר, גלויה. ספירת הימים הכוללת כאן היא בלעדי- הפער בין התאריכים - אז שני עד שישי כתוב כ-4. ממש מתחתיו, המחשבון נחשב ימי עסקים (שני עד שישי, סופי שבוע לא נכללים) באמצעות המוסכמה הכוללת שבה Excel's NETWORKDAYS משתמש, והוא גם אומר לך כמה ימי סוף שבוע הוא ירד, כך שאותו טווח שני עד שישי נקרא כ-5 ימי עבודה. לראות סך בלעדי וספירת ימי עבודה כוללת באותה תצוגה היא תזכורת יומית קטנה לכך ש-" כמה ימים" יש שתי תשובות נכונות תלוי אם אתה סופר את שתי נקודות הקצה. ההחזר שלי בסך $9 קרה בגלל שהקוד שלי ענה על השאלה הבלעדית בזמן שדף התמחור שלי שאל את השאלה הכוללת - וכלי שמציג את שתי המוסכמות בבת אחת הוא כלי שעוצר ממך לבחור אחת בטעות.
עובד על פני חודשים, שנים מעוברות ומאות שנים
בפברואר יש 28 ימים למעט כאשר יש לו 29; 2024 הייתה שנה מעוברת, 2100 won' t להיות למרות היותו מתחלק ב-4 (כלל המאה הגרגוריאנית שתופס את כולם). המחשבון מקבל את כל זה נכון מכיוון שהוא משתמש בכללי לוח שנה אמיתיים ולא ב-" שנה היא 365.25 ימים" קירובים. אם אתה ' אי פעם נזקקת לספירת הימים עבור טווח תאריכים המשתרע על פני פברואר בשנה מעוברת - צבירת ריבית, חלונות SLA, חישובי גיל ליד יום הולדת 29 בפברואר - אתה יודע שמקרי הקצה האלה הם בדיוק המקום שבו מתמטיקה מגולגלת ביד נכשלת.
מיידי, ללא הרשמה, ללא העלאה
תאריכים נכנסים, התשובה יוצאת, לגמרי בצד הלקוח שום דבר לא מועבר או מאוחסן ברוב מתמטיקה של תאריכים זה נוחות ולא אבטחה - אבל לא תמיד. תאריכי העסקה, לוחות זמנים רפואיים, מועדי ליטיגציה: צמדי תאריכים יכולים להיות רגישים בשקט, ושם' אין סיבה שמחשבון יראה אותם אי פעם בצד השרת. הכלי נטען מהר ועובד במצב לא מקוון לאחר הטעינה, מה שהופך אותו גם לדבר שאליו אתה מגיע באמצע הפגישה כשמישהו שואל " רגע, כמה זמן הכרטיס הזה פתוח?"
כיצד להשתמש במחשבון הפרש התאריכים
שלב 1: הזן את תאריך ההתחלה
פתח את מחשבון הבדלי תאריך וקבע את התאריך הראשון השתמש בבורר, הקלד אותו ישירות או לחץ על כפתור היום כדי להצמיד אותו לתאריך הנוכחי. There' הוא שדה זמן אופציונלי (HH:mm) אם אתה צריך את הסכומים עד לשעה או לדקה ולא מחצות עד חצות. אם נתוני המקור שלך הם חותמת זמן של Unix או מחרוזת ISO 8601 עם רכיב זמן, פתור אותו תחילה לתאריך לוח שנה - והיה מכוון לגבי אזור הזמן, כי 1751846400 הוא 7 ביולי בטוקיו ועדיין 6 ביולי בלוס אנג'לס. ה ממיר חותמת זמן מטפל בתרגום הזה.
שלב 2: הזן את תאריך הסיום
הגדר את התאריך השני. Order doesn't need to worry you - a difference is a magnitude, and there's a swap button if you want to flip start and end allow.שווה כאן מחשבה מכוונת: האם תאריך הסיום שלך הוא היום האחרון של התקופה או היום הראשון לאחר זה? מנוי ש-" מסתיים ב-31 בדצמבר" ואחד ש-" מחדש את 1 בינואר" תאר את אותה תקופה עם תאריכי סיום שונים, וזהו המקור הנפוץ ביותר לחילוקי דעות של יום אחד בין שני אנשים שמחשבים את "same" טווח.
שלב 3: קרא את ההבדל ביחידה שאתה צריך
התוצאה מראה את הפער בין יחידות קח את הבעיה שלך נקובת, והתנגד להמיר ביניהן ביד לאחר מכן - "6 חודשים" ו-"182.5 ימים" אינם ניתנים להחלפה, כי החודשים הם 't באורך קבוע אם התשובה תיכנס לחוזה, חשבונית או SLA, ציין את היחידה ו מוסכמות הספירה ("30 ימים קלנדריים, ללא תאריך ההתחלה") כך שהאדם הבא יעשה זאת 't מציג מחדש את העמימות שזה עתה פתרת.
שלב 4: בדיקת שפיות נגד הקוד שלך
אם אתה' משתמשים במחשבון כדי לנפות באגים ביישום, השוו את התשובה שלו מול מה שהקוד שלכם מייצר עבור אותו זוג תאריכים אי התאמה של יום אחד בדיוק פירושה בעיית עמוד גדר או אזור זמן-גבול אי התאמה של יום חלקי פירושה חלוקה של אלפיות השנייה על פני שינוי DST אי התאמה של יומיים או שלושה סביב סוף חודש פירושה הצפה אריתמטית של חודש גודל של השגיאה היא האבחנה - עוד על כל אחד מאלה להלן.
צלילה עמוקה טכנית: מדוע מתמטיקה תאריך משתבשת
אריתמטיקה של תאריכים נראית כמו חיסור והיא למעשה ערימה של חוקי לוח שנה, פוליטיקה של אזור זמן ועמימות הגדרות. חמישה מצבי כשל מהווים כמעט כל באג I' נשלח או נבדק.
1. בעיית עמוד הגדר (לא באחד). בין יום 1 ליום 15 יש 14 מרווחים אבל 15 ימים אם סופרים את שני הקצוות אף אחד מהמספרים אינו "ההבדל" עד שתציין את המוסכמה לילות במלון, ריבית הלוואה ותקופות השכרה משתמשים בספירה בלעדית; מרשמים, משכי אירועים ו-"ימים של כיסוי" בדרך כלל משתמשים כולל דפוס הבאגים: חלק אחד של מערכת משתמש בכל אחד מהם. כתוב את המוסכמה.
2. חודשים אינם יחידה. "חודש לאחר 31 בינואר" אין תשובה ברורה - 31 בפברואר does't exist. JavaScript's legacy Date מטפל בזה על ידי הצפה: new Date(2026, 0, 31) בנוסף חודש אחד נוחת ב-3 במרץ (28 בפברואר + 3 ימי הצפה). PHP's strtotime('+1 month') עושה את אותו הדבר רוב בני האדם, ורוב מערכות החיוב, רוצים הידוק clamping במקום זאת: 31 בינואר + 1 חודש = 28 בפברואר (או 29). הספריות שונות - תאריך-fns ו-Carbon clamp כברירת מחדל בעוזרי הוספת החודש שלהם, גולמיים Date הצפות - והחדש API זמני הופך את ההתנהגות לאפשרות מפורשת, שהיא העיצוב הנכון. אם האפליקציה שלך עושה משהו חודשי עם תאריכי עוגן אחרי ה-28, זה הבאג שיש לך, בין אם אתה' מצאת אותו עדיין או לא.
3. יום הוא לא תמיד 24 שעות. בכל אזור זמן ששומר על שעון קיץ, יום אחד בשנה נמשך 23 שעות ואחר נמשך 25. קוד שמחשב את הבדלי היום כ milliseconds / 86_400_000 מייצר מספר לא שלם בכל פעם שהטווח חוצה מעבר, ואחריו Math.round vs Math.floor הבחירה מחליטה אם אתה' כבוי באחד. הגישה החזקה היא לעשות חשבון יום בתאריכי לוח שנה, לא ברגעים - או לנרמל הכל ל-UTC, שאין לו DST, לפני החלוקה.
4. תאריך ללא אזור זמן אינו רגע בזמן. "2026-07-06" הוא ברוחב 24 שעות טווח שמתחיל ומסתיים ברגעים שונים בכל אזור זמן. הגרסה המגעילה ביותר של הבאג הזה ב-JavaScript: new Date("2026-07-06") מנתח כמו חצות UTC לפי מפרט ECMAScript, אז בכל אזור זמן ממערב לגריניץ' זה מופיע ב-5 ביולי. הפסדתי את רוב אחר הצהריים לזה בלוח מחוונים של React שבו הוא מתוארך ל-Postgres DATE העמודה הוצגה יום אחד מוקדם עבור משתמשים בארהב - העמודה הייתה בסדר, ה-API היה בסדר, הבנאי היה הבאג. אם אתה לוקח שורה אחת מהמאמר הזה: לעולם אל תזין חשוף YYYY-MM-DD מחרוזת ל new Date() כאשר הפרשנות בזמן המקומי חשובה.
5. ISO 8601 הוא התשובה לשאלה אחרת. ISO 8601 (2026-07-06, big-endian, אפס מרופד) פותר תאריך ייצוג- it's חד משמעי איפה 07/06/2026 פירושו 6 ביולי באוהיו ו-7 ביוני באוקספורד, והוא ממיין לקסיקוגרפית השתמש בו בכל יומן, API ושם קובץ. אבל זה לא עושה כלום לתאריך אריתמטיקה; לזוג מועדי ISO בפורמט מושלם עדיין יש את כל ארבע הבעיות שלמעלה. דיסציפלינה בפורמט ודיסציפלינה במתמטיקה הם דיסציפלינות נפרדות.
המטא-שיעור: השתמש בספריית לוח שנה אמיתית (תאריך-fns, Luxon, Carbon או Temporal כאשר המטרות שלך תומכות בו), בצע חשבון במרחב לוח שנה ולא במרחב של אלפיות שניות, ואמת מקרי קצה - קצוות חודש, ימים מעוברים, DST סופי שבוע - מול מקור עצמאי כמו ה מחשבון calculator. אימות עצמאי הוא כל העניין של כלי עבודה; עוד על הפילוסופיה הזו ב מדריך ממיר חותמת זמן.
מקרי שימוש נפוצים
תקופות חיוב ואורכי ניסיון
מערכות מנוי חיות ומתות על מתמטיקה של תאריך. Proration צריך ספירת ימים מדויקת בתוך תקופת חיוב; ניסויים צריכים תאריך סיום חד משמעי; תוכניות שנתיות צריכות לשרוד את ה-29 בפברואר. בעת בניית תזרימי תשלום אני מחשב כעת כל גבול תקופה פעמיים - פעם אחת בקוד, פעם אחת במחשבון - לפני כתיבת המבחן. זה תפס באגים אמיתיים לפחות ארבע פעמים, תמיד בסוף החודש או בקצוות DST, ותמיד מהסוג שאחרת היה מופיע כדואל מבולבל של לקוחות. אם הכסף מתרבה מול ספירת ימים בכל מקום במערכת שלך, ודא את ספירת הימים באופן עצמאי.
מועדי פרויקט ותכנון ספרינט
"כמה שבועות עבודה מעכשיו ועד תאריך השחרור?" עולה בכל פגישת תכנון, והתשובה שאנשים מחשבים בראשם מבוטלת באופן אמין באחד או שניים - בני אדם גרועים בספירה מעבר לגבולות החודש. השגת פער לוח השנה האמיתי בימים ושבועות אורכת חמש שניות ומבססת את השיחה. משם אתה מפחית חגים וחוצץ בכנות, במקום להתחיל ממספר שכבר היה אופטימי בשבוע.
חישובי חוזה, הודעה ומועד אחרון
תאריכים משפטיים ומשאבי אנוש מגיעים עם מוסכמות לא סלחניות: תקופת הודעה מוקדמת של 90 יום, חלון ריפוי של 30 יום, הגשת מועד " תוך 21 ימי שירות." אלו בדיוק שדות המוקשים הכוללים לעומת בלעדיים, והעלות של איחור ביום אחד גרועה באופן מוחלט מהעלות של איחור ביום אחד. חשב את הטווח, ואז אשר באיזו מוסכמה של נקודת הקצה המסמך משתמש. (ולכל דבר שחשוב באמת, עורך דין מנצח מחשבון - הכלי אומר לך את הספירה, לא את תחום השיפוט 's כללי ספירה.)
חישובי גיל וקביעות
גילאים, שנות שירות, משך חיי החשבון - הכל " הבדל בשנים וחודשים" בעיות עם כלל הידוק שמסתתר בפנים (למי שנולד ב-29 בפברואר יש יום הולדת חוקי של 28 בפברואר או 1 במרץ בהתאם לתחום השיפוט, וזה דבר אמיתי שהמהנדסים נאלצו לקודד). לתשובה מהירה - בן כמה החשבון הזה, כמה זמן מאז הפריסה האחרונה, כמה ימים מאז האירוע - המחשבון נותן את הנתון המדויק מבלי לטעון REPL.
בדיקות שפיות נתונים
כאשר דוח אומר הפער הממוצע הזמנה למסירה הוא 47 ימים ואת הבטן שלך אומר שבועיים, לקחת שורה בפועל ולבדוק את שני התאריכים ביד. מחצית מהזמן את "bug" הוא שינוי אזור זמן או חודש / יום הוחלף בניתוח במעלה הזרם. בדיקת נקודתית של שלוש או ארבע שורות מול מחשבון מהימן היא הדרך המהירה ביותר להחליט אם לא לסמוך על הצינור או על המעיים שלך. עבור eyeballing מה השתנה בין שני דוחות מיוצאים, ה כלי Text Diff משתלב היטב עם זרימת עבודה זו.
ספירת מוסכמות בהשוואה
| אֲמָנָה | שני → ו' שווה | משמש ל | להיזהר מ |
|---|---|---|---|
| בלעדי (פער) | 4 ימים | לילות במלון, צבירת ריבית, גיל בימים | מרגיש "one short" לקוראים שאינם טכניים |
| כולל (span) | 5 ימים | ימי תרופות, משכי אירועים, "ימי כיסוי ומזימה; | Off-by-one כאשר מעורבב עם מערכות בלעדיות |
| ימי עסקים | 4 או 5 פחות חגים | SLAs, הערכות משלוח, מועדים חוקיים | לוחות השנה של החגים שונים לפי מדינה ואפילו לפי חוזה |
| תקופות מדויקות של 24 שעות | תלוי בזמנים | השכרות, חניה, חלונות תעריף API | DST עושה יום מקומי אחד 23h ועוד 25h |
| חודשים/שנים קלנדריים | "1 חודש לאחר מכן" | מחזורי חיוב, חוזים, שכירות | אורכי החודש משתנים; הידוק לעומת הצפה בסוף החודש |
הטבלה's הודעה אמיתית: "כמה זמן בין התאריכים הללו" היא לא שאלה אחת בחר את השורה התואמת את הבעיה שלך, שם אותה במפורש בקוד שלך ובעותק שלך, וכל קטגוריית המחלוקת נעלמת זו אותה משמעת בשאר ה ערכת כלים למפתחי אינטרנט ממשיך לדחוף - הפוך את המרומז למפורש וחצי מהחרקים שלך מתאדים.
שָׁוא
מהו מחשבון הפרש תאריכים?
מחשבון הפרש תאריכים מחשב את הפער המדויק בין שני תאריכים לוח שנה, המתבטאים בימים, שבועות, חודשים ושנים. בניגוד למתמטיקה מנטלית או חיסור נאיבי של אלפיות השנייה, הוא מיישם כללי לוח שנה אמיתיים - אורכי חודשים משתנים, שנים מעוברות, חוקי מאה - כך שהתוצאה נכונה על פני מקרי קצה כמו פברואר בשנה מעוברת או טווחים המשתרעים על מעברי שעון קיץ.
איך אני מחשב את מספר הימים בין שני תאריכים?
הזן את שני התאריכים לתוך מחשבון הבדלי תאריך וקרא את ספירת הימים עשה זאת ביד, לספור את הימים הנותרים בחודש ההתחלה, להוסיף את החודשים המלאים בין, ואז להוסיף את הימים לתוך החודש הסופי - ולהחליט מראש אם לספור את תאריך הסיום עצמו ההחלטה האחרונה, כולל לעומת ספירה בלעדית, היא המקום שבו רוב החישובים הידניים משתבשים באחד.
האם תאריך הסיום כלול בספירת ימים בין תאריכים?
לפי מוסכמה, לא - התקן "difference" הוא בלעדי, סופר את המרווחים בין התאריכים, כך שני עד שישי הוא 4 ימים. אבל הקשרים רבים בעולם האמיתי (לוחות זמנים לתרופות, תקופות כיסוי, אורכי אירועים) נחשבים באופן כוללני, מה שהופך אותו ל-5. אף אחד מהם אינו שגוי; הם עונים על שאלות שונות. תמיד ציין באיזו מוסכמה אתה ' משתמשים כאשר המספר נכנס לחוזה או לחשבונית.
מדוע מתמטיקה תאריך JavaScript שלי לתת תשובה אחרת?
שלושה חשודים רגילים: new Date("YYYY-MM-DD") מנתח מחרוזות תאריך חשופות כחצות UTC, מעביר את התאריך ביום באזורי זמן מערביים; חלוקת הפרשי אלפיות השנייה ב-86,400,000 הפסקות על פני מעברי DST שבהם יום הוא ' t 24 שעות; והוספת חודשים עם אובייקט התאריך מדור קודם עולה על גדותיו בסוף החודש (31 בינואר + 1 חודש = 3 במרץ). השתמש בספרייה מודעת ללוח שנה כמו date-fns, Luxon או Temporal API במקום אריתמטיקה גולמית.
איך סופרים חודשים כשיש להם אורכים שונים?
הבדלי חודשים מחושבים בלוח השנה, לא על ידי חלוקת ימים בממוצע: 15 במרץ עד 15 בספטמבר הוא בדיוק 6 חודשים למרות שזה 's 184 ימים. העמימות מופיעה עם תאריכי עוגן לאחר ה-28 - חודש לאחר ה-31 בינואר מהודק בדרך כלל ל-28 או 29 בפברואר. מהדק מערכות חיוב מתנהגים היטב; קוד נאיבי עולה על גדותיו לתחילת מרץ, שהוא באג אמיתי ששווה לבדוק עבורו.
האם שנים מעוברות משפיעות על הפרש התאריכים?
כן - כל טווח שמתפרש על פני 29 בפברואר בשנה מעוברת (כמו 2024 או 2028) מכיל יום אחד יותר מאותו טווח בשנה משותפת, ומחשבונים נכונים מסבירים זאת באופן אוטומטי הכלל העדין: שנים המתחלקות ב-100 אינן שנים מעוברות אלא אם כן מתחלקות גם ב-400, כך ש-2000 הייתה שנה מעוברת אבל 2100 won't be. Hand-rolled " divisible by 4" המחאות נכשלות בדיוק באותן שנים.
כיצד משפיעים אזורי זמן על חישוב ימים בין תאריכים?
תאריך חשוף הוא חלון שונה של 24 שעות בכל אזור זמן, כך ששתי מערכות באזורים שונים יכולות לחלוק באופן לגיטימי על מה " today" הוא - וחותמת זמן ליד חצות יכולה ליפול בתאריכי לוח שנה שונים בהתאם לאזור המשמש לפירושו. עבור הבדלי תאריך לוח שנה טהורים, אזורי זמן don't חלים; עבור תאריכים שמקורם בחותמת זמן, המר תחילה את שתי חותמות הזמן לאותו אזור באמצעות כלי כמו ממיר חותמת זמן.
האם מחשבון הפרש התאריכים Toolz.dev חינמי ופרטי?
כן בשני הסעיפים. זה פועל כולו בדפדפן שלך ללא הרשמה - התאריכים שאתה מזין לעולם אינם מועלים, נרשמים או מאוחסנים בשום מקום. זה חשוב יותר ממה שזה נראה, מכיוון שצמדי תאריכים יכולים לקודד עובדות רגישות כמו תקופות עבודה, לוחות זמנים רפואיים או מועדים חוקיים, ו-there' אין סיבה טכנית שמחשבון צריך לראות אותם בצד השרת.
