Erfinde die Zeit nicht neu, du machst es wahrscheinlich falsch 
 
 TL;DR: Zeit ist nicht absolut. Ihr Code bricht, wenn Sie es so behandeln. TL;DR: Zeit ist nicht absolut. Ihr Code bricht, wenn Sie es so behandeln. Probleme 
 
 
 
 
 
 
 
 Falsche Dauer Die Zeit des Chaos gebrochener Zeitplan Datum Parsing Defekte Invalid Timestamps Globale Daten Tests abhängig von Dates Lösungen 
 
 
 
 
 
 
 
 
 
 Verwenden Sie solide Bibliotheken Vermeiden Sie Systemuhr Vertrauen Normalisieren Sie alle Timestamps Test mit Edge Cases Zeit umarmen seltsamkeit Immer Zeitzonen einschließen Überprüfen Sie alle Zeitzonen Scheitern schnell Behandeln Sie Timestamps als Timestamps Zusammenhang Du denkst, ein Tag hat 24 Stunden, Wochen beginnen am Montag, oder Februar hat immer 28 Tage. Ihre Benutzer in Ouagadougou erhalten eine doppelte Mitternacht, und Ihre Backups überspringen einen Tag in Sydney. Zeit-Illusionen tauchen in Ihren Code ein, wenn Sie davon ausgehen, dass es einfach ist. Sie bauen Logik auf, die während von Tageslicht-sparenden Änderungen, Sprung Sekunden oder sogar, wenn die Uhr schwebt, fehlschlägt. Programmierer kämpfen oft mit Zeitmanagement. Wenn Sie mit der Zeit in Ihren Anwendungen arbeiten, stehen Sie vor einer der betrügerischsten Herausforderungen der Programmierung. Die meisten Entwickler beginnen, indem sie einfache Zeitberechnungen schreiben, unter der Annahme, dass Tage immer 24 Stunden haben, Monate konsistente Längen haben und Zeitzonen statisch bleiben. Diese Annahmen erzeugen dass die Oberfläche Monate oder Jahre später, wenn Ihre Anwendung mit Echtzeit-Szenarien konfrontiert. Defizite Zeitmanagement ist ein perfektes Beispiel für die Je mehr man über Zeit lernt, desto mehr merkt man, wie wenig man weiß. Der Dunning-Kruger Effekt Politische Entscheidungen ändern die Zeitzonen, Sprung-Sekunden passen die Atomzeit an und kulturelle Unterschiede beeinflussen Kalender-Systeme weltweit. Sample Code Falsch 🙂 from datetime import datetime, timedelta

class TimeCalculator:
    def add_business_days(self, start_date, days):
        # Assumes every day has 24 hours
        result = start_date
        for _ in range(days):
            result += timedelta(days=1)
            # Skip weekends
            while result.weekday() >= 5:
                result += timedelta(days=1)
        return result
    
    def get_monthly_report_date(self, year, month):
        # Assumes all months have 31 days
        return datetime(year, month, 31)
    
    def calculate_age(self, birth_date):
        # Ignores leap years and timezone changes
        today = datetime.now()
        return (today - birth_date).days // 365
    
    def schedule_meeting(self, base_time, timezone_offset):
        # Assumes timezone offset never changes
        return base_time + timedelta(hours=timezone_offset)
    
    def is_same_day(self, time1, time2):
        # Compares without considering timezone
        return time1.date() == time2.date()
 Richtig 🙂 import pytz
from datetime import datetime, timedelta
from dateutil.relativedelta import relativedelta
from zoneinfo import ZoneInfo

class TimeHandler:
    def __init__(self, timezone='UTC'):
        self.timezone = ZoneInfo(timezone)
    
    def add_business_days(self, start_date, days):
        """Add business days accounting for timezone and DST"""
        if not start_date.tzinfo:
            start_date = start_date.replace(tzinfo=self.timezone)
        
        result = start_date
        days_added = 0
        
        while days_added < days:
            result += timedelta(days=1)
            # Skip weekends
            if result.weekday() < 5:
                days_added += 1
        
        return result
    
    def get_monthly_report_date(self, year, month):
        """Get last day of month safely"""
        next_month = datetime(year, month, 1, 
             tzinfo=self.timezone) + relativedelta(months=1)
        return next_month - timedelta(days=1)
    
    def calculate_age(self, birth_date):
        """Calculate age accounting for leap years"""
        if not birth_date.tzinfo:
            birth_date = birth_date.replace(tzinfo=self.timezone)
        
        today = datetime.now(self.timezone)
        return relativedelta(today, birth_date).years
    
    def schedule_meeting(self, base_time, target_timezone):
        """Schedule meeting with proper timezone handling"""
        if not base_time.tzinfo:
            base_time = base_time.replace(tzinfo=self.timezone)
        
        target_tz = ZoneInfo(target_timezone)
        return base_time.astimezone(target_tz)
    
    def is_same_day(self, time1, time2, timezone):
        """Compare dates in specific timezone"""
        tz = ZoneInfo(timezone)
        local_time1 = time1.astimezone(tz)
        local_time2 = time2.astimezone(tz)
        return local_time1.date() == local_time2.date()
 Erkundung 
 
 [x] halbautomatisch Sie können diesen Geruch erkennen, wenn Sie hardcodierte Zeitberechnungen, Annahmen über Tageslängen, Zeitzonen-naive Datetime-Operationen oder benutzerdefinierte Datum-Arithmetik sehen. Suche nach wie 86400 (Sekunden in einem Tag), 365 (Tage in einem Jahr) oder hardcodierte Zeitzonenkompensationen. Magische Zahlen Achten Sie auf Datetime-Operationen, die keine Zeitzonen angeben, Sprungjahresberechnungen mit einfacher Teilung oder jeden Code, der Zeit als rein mathematisch behandelt, ohne politische und physikalische Realitäten zu berücksichtigen. Tags ️ 
 
 Zeit Ebene 
 
 [x] Zwischenzeit Warum die Bijection wichtig ist ️ Die Zeit in der realen Welt ist verschwommen, politisch und voller Ausnahmen. Wenn Ihr Programm es als linear und perfekt modelliert, führen Sie eine . Karte Dieses Missverhältnis führt zu Sie sind unmöglich zu reproduzieren und schwer zu erklären. Defizite Sie müssen Zeit auf eine Weise darstellen, die ihr Verhalten widerspiegelt: mit Kontext, Regeln und Variabilität. Wenn Ihr Code ein vereinfachtes Zeitverhalten annimmt, brechen Sie die Übereinstimmung zwischen dem Zeitmodell Ihres Programms und der Realität. Dies schafft die zufällig erscheinen, wenn Ihre Anwendung mit Echtzeit-Szenarien wie Übergangsjahre oder Wechsel der Zeitzone. Defizite Tageslicht Zeit sparen Die Aufrechterhaltung der Bijection bedeutet, die wahre Komplexität der Zeit zu respektieren und etablierte Bibliotheken zu verwenden, die diese Randfälle richtig behandeln. Brechen Sie dies führt zu Planungsfehlern, falschen Altersberechnungen und Datenkorruption in zeitempfindlichen Anwendungen. Korrespondenz Sie können kein Datum mit einem Tag des 30. Februar erstellen. Sie müssen den Das Prinzip. Scheitern schnell Die Generation Oft wird angenommen, dass Viele generierte Beispiele ignorieren Zeitzonen, DST-Änderungen und korrigieren sogar das Parsen. Neues Datum() KI-Code-Generatoren erstellen manchmal Zeitverarbeitungskode mit gängigen Fälschungen. Sie generieren oft einfache Datum-Arithmetik, hardcoded Zeitzonen-Annahmen und naive Datetime-Operationen, weil diese Muster manchmal in Trainingsdaten auftreten. Die Erkennung Wenn Sie die KI bitten, "Zeitzonen richtig zu behandeln" oder "Tagesschutz zu vermeiden" ," es kann besseren code generieren. aber es braucht klare anweisungen. die standard-ausgabe ist in der regel falsch. Defizite KI-Tools können Zeitbehandlungsfehler erkennen, wenn Sie spezifische Anweisungen über Zeitzonenbewusstsein, Sprungjahr-Behandlung und DST-Bedenken geben. Sie müssen diese Überprüfungen explizit anfordern, da KI keine zeitbezogenen Annahmen automatisch identifiziert. Probieren Sie es aus! Denken Sie daran: AI-Assistenten machen viele Fehler 
 
 Vorschlag Prompt: "Überprüfen Sie diesen Zeitverwaltungskodex für häufige Falschmeldungen über die Zeit. Überprüfen Sie Timezone-naive Operationen, hardcoded Tag / Monat Längen, Sprungjahr Annahmen und DST Handling. Vorschlagen Sie Verbesserungen mit etablierten Zeitbibliotheken und ordnungsgemäße Timezone Handling." Vorschlag Prompt: "Überprüfen Sie diesen Zeitverwaltungskodex für häufige Falschmeldungen über die Zeit. Überprüfen Sie Timezone-naive Operationen, hardcoded Tag / Monat Längen, Sprungjahr Annahmen und DST Handling. Vorschlagen Sie Verbesserungen mit etablierten Zeitbibliotheken und ordnungsgemäße Timezone Handling." 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Without Proper Instructions 
 With Specific Instructions 
 
 
 
 ChatGPT 
 ChatGPT 
 
 
 
 Claude 
 Claude 
 
 
 
 Perplexity 
 Perplexity 
 
 
 
 Copilot 
 Copilot 
 
 
 
 You 
 You 
 
 
 
 Gemini 
 Gemini 
 
 
 
 DeepSeek 
 DeepSeek 
 
 
 
 Meta AI 
 Meta AI 
 
 
 
 Grok 
 Grok 
 
 
 
 Qwen 
 Qwen ChatGPT ChatGPT Claude Claude Verwirrung Verwirrung Kinderpilot Kinderpilot Du bist Du bist Gemini Gemini DeepSeek DeepSeek Ziel ist AI Ziel ist AI Groke Groke QWEN QWEN Schlussfolgerung Wenn du die Zeit als einfach behandelst, lügt dein Code.Die Zeit ist ein tief gebrochenes Konzept mit Politik, Ausnahmen und Drift. Respektiere es und schreibe niemals deine eigene Datumslogik. Verwenden Sie Bibliotheken, die Jahrzehnte damit verbracht haben, Dinge zu reparieren, die Sie nicht einmal sehen können. Ihre Anwendungen werden zuverlässiger, wenn Sie die wahre Natur der Zeit respektieren und von Anfang an angemessene Zeitverwaltungspraxis anwenden. Beziehung https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-viii-8mn3352 https://hackernoon.com/code-smell-246-modeling-expiration-dates https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxxix https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xli https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xvi Weitere Informationen https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca?embedable=true https://www.nasa.gov/solar-system/moon/nasa-to-develop-lunar-time-standard-for-exploration-initiatives/?embedable=true https://hackernoon.com/fail-fast-philosophy-explained-si963vk9?embedable=true https://en.wikipedia.org/wiki/Dunning–Kruger_effect Disclaimer Code Gerüche sind meine . Meinungen Kredite Foto von ist von Luis Cortes Unsplash 
 
 Ein Tag kann 23 Stunden sein. oder 25. Du hast es einfach vergessen. Ein Tag kann 23 Stunden sein. oder 25. Du hast es einfach vergessen. von Paul Ford https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true Dieser Artikel ist Teil der CodeSmell-Serie. https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd?embedable=true

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - REFACTORING.

2020 - Hacker Noon Contributor of the Year in REFACTORING

2022 - HackerNoon Contributor of the Year - Clean Code

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Github

2022 - HackerNoon Contributor of the Year - Machine Learning

2022 - HackerNoon Contributor of the Year - Quality Assurance

2022 - HackerNoon Contributor of the Year - Refactoring

2022 - HackerNoon Contributor of the Year - Software Architecture

2022 - the Greatest Storyteller

Buy My Book

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Software Engineer and Book Author

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Zu lang; Lesen

Make resilience your competitive advantage

Code Smell 307 - Naive Zeitvermutungen und wie man es behebt

Code Smell 307 - Naive Zeitvermutungen und wie man es behebt

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

Welcome to HackerNoon Decoded: The Best of 2024 Tech Blogging

HackerNoon Decoded 2024: Celebrating Our Cybersecurity Community!

HackerNoon Decoded 2024: Wir feiern die Community unserer Technologieunternehmen!

HackerNoon Decoded 2024: Wir feiern unsere Produktmanagement-Community!

Welcome to HackerNoon Decoded: The Best of 2024 Tech Blogging

HackerNoon Decoded 2024: Celebrating Our Cybersecurity Community!

HackerNoon Decoded 2024: Wir feiern die Community unserer Technologieunternehmen!

HackerNoon Decoded 2024: Wir feiern unsere Produktmanagement-Community!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps