Non reinventare il tempo, probabilmente lo stai facendo male 
 
 TL;DR: Il tempo non è assoluto.Il tuo codice si rompe quando lo tratti in questo modo. TL;DR: Il tempo non è assoluto.Il tuo codice si rompe quando lo tratti in questo modo. Problemi 
 
 
 
 
 
 
 
 Durata sbagliata Tempi di caos Orario rotto Data di rilevamento dei difetti Timestamp Invalidi Dati globali Test in base alle date Soluzioni 
 
 
 
 
 
 
 
 
 
 Utilizzare le librerie solide Evitare l’orologio del sistema Normalizza tutti i timestamp Test con i casi edge Abbracciamo il tempo della bizzarra Includere sempre i fusi orari Controlla tutti gli orari fallimento rapido Tratta i timestamps come timestamps Il contesto Si pensa che un giorno abbia 24 ore, le settimane iniziano il lunedì, o che febbraio abbia sempre 28 giorni. I tuoi utenti a Ouagadougou otterranno una doppia mezzanotte, e i tuoi backup salteranno un giorno a Sydney. Le illusioni del tempo entrano nel tuo codice quando presumi che sia semplice. Costruisci una logica che fallisce durante i cambiamenti che risparmiano la luce del giorno, i secondi di salto o anche quando l'orologio scorre. I programmatori spesso lottano con la gestione del tempo. Quando lavori con il tempo nelle tue applicazioni, affronti una delle sfide più ingannevoli della programmazione. La maggior parte degli sviluppatori inizia scrivendo semplici calcoli di tempo, presumendo che i giorni abbiano sempre 24 ore, i mesi abbiano lunghezze coerenti e le fuse orarie rimangano statiche. Queste ipotesi creano che la superficie mesi o anni dopo quando la tua applicazione incontra scenari in tempo reale. difetti La gestione del tempo rappresenta un perfetto esempio del Più impari sul tempo, più ti rendi conto di quanto poco sai. Effetto Dunning-Kruger Le decisioni politiche cambiano i fusi orari, i secondi di salto regolano il tempo atomico e le differenze culturali influenzano i sistemi di calendario in tutto il mondo. Modulo di codice sbagliato 🙂 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()
 giusta 🙂 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()
 Riconoscimento 
 
 [x] Semiautomatico È possibile rilevare questo odore quando si visualizzano calcoli di tempo hardcoded, ipotesi sulle lunghezze del giorno, operazioni date time-zone-naive, o aritmetica della data personalizzata. Cerca di come 86400 (secondi in un giorno), 365 (giorni in un anno), o compensazioni di fuso orario codificate. Numeri magici Attenzione alle operazioni di datetime che non specificano zone temporali, ai calcoli di anno salto utilizzando una semplice divisione, o a qualsiasi codice che tratti il tempo come puramente matematico senza considerare le realtà politiche e fisiche. Giorno ️ 
 
 Il tempo Livello 
 
 [x] Intermediario Perché la bijection è importante ️ Il tempo nel mondo reale è vago, politico e pieno di eccezioni. Se il tuo programma lo modella come lineare e perfetto, introduci una non corrispondenza alla . Mappa Questo disaccordo porta a Impossibile riprodurre e difficile da spiegare. difetti È necessario rappresentare il tempo in un modo che rifletta il suo comportamento: con il contesto, le regole e la variabilità. Quando il codice assume un comportamento temporale semplificato, si rompe la corrispondenza tra il modello temporale del programma e la realtà. Questo crea che appaiono in modo casuale quando la tua applicazione incontra scenari in tempo reale come transizioni, anni di salto o cambiamenti di fuso orario. difetti Il tempo di risparmio della luce Mantenere la bijection significa rispettare la vera complessità del tempo e utilizzare le librerie stabilite che gestiscono correttamente questi casi di margine. rompere questo porta a errori di pianificazione, calcoli di età errati e corruzione dei dati in applicazioni sensibili al tempo. Corrispondenza Non è possibile creare una data con un giorno del 30 febbraio. Devi seguire il Il principio. fallimento rapido La generazione Spesso si assume Molti esempi generati ignorano i fusi orari, i cambiamenti DST e persino correggono il parsaggio. Nuova data ( I generatori di codici AI a volte creano codici di gestione temporale con falsehoods comuni. Spesso generano semplici aritmetiche di data, ipotesi di fuso orario codificate e operazioni date-time ingenue perché questi modelli a volte si verificano nei dati di formazione. La rilevazione Se chiedi all'IA di "trattare correttamente le fuse orarie" o "evitare di risparmiare luce del giorno" ," può generare codice migliore. ma ha bisogno di istruzioni chiare. La uscita predefinita è di solito sbagliata. difetti Gli strumenti AI possono rilevare errori di gestione del tempo quando fornisci istruzioni specifiche sulla consapevolezza del fuso orario, la gestione dell'anno salto e le considerazioni DST. Devi chiedere esplicitamente questi controlli, poiché l'IA non identificerà automaticamente i presupposti legati al tempo. Prova a farlo! Ricordate: gli assistenti AI commettono molti errori 
 
 Prompt suggerito: "Rivisiona questo codice di gestione del tempo per le falsehoods comuni riguardo al tempo. Controlla le operazioni timezone-naive, le lunghezze giorno/mese codificate, le ipotesi di anno salto e la gestione DST. Suggerisci miglioramenti utilizzando biblioteche temporali stabilite e la gestione del fuso orario appropriata." Prompt suggerito: "Rivisiona questo codice di gestione del tempo per le falsehoods comuni riguardo al tempo. Controlla le operazioni timezone-naive, le lunghezze giorno/mese codificate, le ipotesi di anno salto e la gestione DST. Suggerisci miglioramenti utilizzando biblioteche temporali stabilite e la gestione del fuso orario appropriata." 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 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 di Claude di Claude Perplessità Perplessità Copilotto Copilotto Tu è Tu è Gemelli Gemelli profondità profondità Obiettivo AI Obiettivo AI Grillo Grillo di Qwen di Qwen Conclusione Quando tratti il tempo come semplice, il tuo codice mentisce.Il tempo è un concetto profondamente rotto ingannato con la politica, le eccezioni e il drift. Rispetta e mai scrivere la tua data logica. Utilizzare le librerie che hanno trascorso decenni riparando ciò che non si può nemmeno vedere. Le tue applicazioni diventeranno più affidabili se rispetti la vera natura del tempo e utilizzi le pratiche di gestione del tempo corrette fin dall'inizio del tuo processo di sviluppo. Relazioni 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 Maggiori informazioni 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 L’odore è mio . opinione Crediti Foto di è Luigi Cortes Unsplash 
 
 Un giorno può essere di 23 ore o di 25 ore, hai appena dimenticato. Un giorno può essere di 23 ore o di 25 ore, hai appena dimenticato. di Paul Ford https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true Questo articolo fa parte della serie CodeSmell. 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

Questo audio è prodotto nella lingua originale della storia!

Troppo lungo; Leggere

Make resilience your competitive advantage

Code Smell 307 - Assunzioni di tempo ingenue e come risolverlo

Code Smell 307 - Assunzioni di tempo ingenue e come risolverlo

About Author

COMMENTI

CARTELLINI

QUESTO ARTICOLO È STATO PRESENTATO IN

Related Stories

Arron Goolsbey Talks Future of Gaming with AI and Blockchain at Mythical Games

How to Mint Your Name.HackerNoon Web3 Identity Namespace

Link-To-Earn Incentive Model: A Blueprint For Mass Adoption?

OpenAI Has Everything Under Control 😎

Arron Goolsbey Talks Future of Gaming with AI and Blockchain at Mythical Games

How to Mint Your Name.HackerNoon Web3 Identity Namespace

Link-To-Earn Incentive Model: A Blueprint For Mass Adoption?

OpenAI Has Everything Under Control 😎

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps