Microsoft har haft travlt i de seneste dage med at skrive en opdatering til Exchange, som nu bliver opdateret som en af de første opgaver i 2022.
Det sker, fordi Microsoft har opdaget, at Exchange i en række tilfælde har haft meget svært ved at tackle skiftet fra 2021 til 2022 i løsningens kalender-system, skriver Computerworld.
Det har betydet, at mails ikke er blevet sendt som planlagt, men i stedet har siddet fast i systemet, og problemet huserer i Exchange Server 2016 og Exchange Server 2019.
Microsoft meddeler, at nytårs-problemet ikke har nogen indvirkning på Exchanges scannings-funktioner, der løbende scanner efter malware - på trods af at problemets årsag ligger netop her.
Dato-problemet betyder nemlig, at malware-motoren crasher, hvilket får mails til at line op i kø i systemet.
Du kan læse mere om fixet hos Microsoft her.
- emailE-mail
- linkKopier link

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
Hvad undrer endnu mere er hvorfor man overhovedet har begivet sig ud i at fedte med en int32, al den stund at selv i C-whatever eksisterer DateTime (omend tDateTime imo er en del mere elegant).Det undrer mig mest, at en udvikler har siddet i 2010'ish og kodet en dato med kun to cifre til årstallet.
@Nicholaj - Unix Epoch time er per definition UTC.
Jo, og så husk at gemme i UTC tid.
De kunne også have brugt de 32 mest betydende bits i ntp's timestamp (som også er brugt andre standarder) - det er antal sekunder siden 1900 (ikke 1970). Og der er rollover i 2036 I NTPv4 (RFC 5905) har man udvidet til at bruge 64 bits til sekunder i ntp timestamp (delt over 32 bits til time era number, og 32 bits til era offset). Så der behøver man ikke at bekymre sig om rollover
Men det lugter også af unix(tm), så det er sikkert var sikkert ikke godt nok...
Er Unix Epoch time ikke et meget godt bud?
Jo, men mon ikke det lugter for meget af unix til at MS kan bruge det?
/Henning
Er Unix Epoch time ikke et meget godt bud?Hvis bare der var en standard som ville gøre det overflødigt at skulle opfinde et format fra bunden.
Denne forskydning foretages nemmest ved at konvertere den angivne dato fra en "string of chars", såfremt den har været præsenteret således overfor brugeren af systemet, til et (hel-)tal.
Hvis bare der var en standard som ville gøre det overflødigt at skulle opfinde et format fra bunden.
Det har vi vel alle gjort i et eller andet omfang.
Forhåbentlig ikke.
Jeg opponerer ikke imod at de har brugt en int til at repræsentere en dato. Hvis bare de havde brugt den som du foreslår, til at repræsentere antal dage efter et givent nulpunkt. De kunne også have brugt en struct, et array af bytes eller andet.
Men det, de har gjort, er at bruge en int som om den var en string.
Altså
int dato = minutter + 100 * timer + 10000 * dag + 1000000 * maaned + 100000000 * (aar % 100);
Så 4. januar 2022 kl. 11:49 gemmes som tallet 2.201.041.149.
Ville du også kunne finde på
int person = skostoerrelse + 100 * husnummer + 10000 * antalKæledyr + 1000000 * yndlingsPizzaNummer + 100000000 * (livvidde % 10); int jørgen = 226003447;
Det har vi vel alle gjort i et eller andet omfang.Men det er endnu mere sært at bruge en int som string. Hvem gør det?
Hvorfor string? Det, der skal gemmes, er ikke en "string of chars" men en dato. Problemet er så, at en digital computer ikke aner, hvad en dato er, så for at gemme den bliver man nødt til at konvertere den til et reversibelt format, der kan gemmes som en række 0'er og 1'er.
Her vil en "string of chars" være et udemærket bud, men det vil en heltalsrepræsentation af antallet af dage siden et fastlagt nulpunkt også være.
I de fleste tilfælde vil det give mening at repræsentere datoen som et antal år, måneder og dage siden en dato, hvor det - i forholdsvis nyere tid - er blevet besluttet, at Jesus blev født. Hans fødselsdag blev senest rettet i oktober 1582 under Pave Gregor 13.
I mange computersystemer har man valgt et nulpunkt, der hedder 1. januar 1970. Valget af 1970 som nulpunkt mere end antyder, at man har tænkt sig at et tidsstempel skal gemmes som en integer, snarere end som en string.
Når man så har valgt, om man vil gemme datoen i et format der henvender sig til mennesker eller computere, så skal man også beslutte om man vil gemme den dato, som brugeren af systemet - i dette tilfælde Exchange - "synes" at det er, eller den dato det ville være, såfremt brugeren befandt sig i bydelen Greenwich i en hovedstad i udlandet.
Eftersom Exchange ofte bruges til mail der kan have en afsender og modtager der befinder sig i forskellige tidszoner, vil det være helt naturligt at gemme den dato der ville være afsender og modtagers "fælles" dato, altså datoen i Greenwich. Men det kræver en forskydning af den angivne dato med en brøkdel af et døgn, der gør at den gemte dato ligger før eller efter den angivne dato. Denne forskydning foretages nemmest ved at konvertere den angivne dato fra en "string of chars", såfremt den har været præsenteret således overfor brugeren af systemet, til et (hel-)tal. Og når man nu har konverteret datoen til et (hel-)tal som man mener er en præcis angivelse, hvorfor så ikke gemme datoen i dette format. Det er trods alt et format, som computeren kan gemme som 0'er og 1'er.
tldr; en string er ikke entydigt en bedre måde at gemme en dato på.
Det undrer mig mest, at en udvikler har siddet i 2010'ish og kodet en dato med kun to cifre til årstallet.
Det er selvfølgelig sært.
Men det er endnu mere sært at bruge en int som string. Hvem gør det?
Hvorfor djævlen får MS ikke én gang for ALLE rette det problem med dato/cock tid.
Jeg er sikker på at de fluks retter det til en unsigned integer og så er det problem løst længe nok (x)... :-)
(x) udvikleren er gået på pension om 21 år. Og hvis ikke, så får han bonus for at gå tilbage og rette det.
Det undrer mig mest, at en udvikler har siddet i 2010'ish og kodet en dato med kun to cifre til årstallet. Y2K blev åbenbart hurtigt glemt.
YYYYMMDDHHMM ville have fanget problemet med at forsøge at bruge en 32 bit signed int med det samme.
Men det kan være, de var tilfredse med i det mindste ikke at have byttet om på måneder og dage...
yyMMddhhmmss som int
Det var naturligvis yyMMddhhmm (uden sekunder)
Det kunne se ud som om det er noget kode der putter datoen i en Int32-variabel som "yyMMddhhmmss" -- det giver overløb når året er "22"
På artiklen om deres "fix" kan man læse:
The version of the updated scan engine starts with 2112330001; is this right? Should we be concerned that it seems to reference a date that does not exist?
Så det lugter jo af at prøve at holde "datoen" under maxint
Hvorfor djævlen får MS ikke én gang for ALLE rette det problem med dato/cock tid.
Hvorfor skal de afsætte så umådeligt lidt plads til dato/tid når de har så uanet enormt meget spil plads på alt deres garbage i deres programmer. Det kan da ikke være en umenneskelig opgave at afsætte 16 eller 64 bit til dato/clock det er jo kun op til 4 bytes og hvis problemet virkeligt er stort, så afsæt 8 bytes uha det er meget spilplads, når vi ser hvor meget spilplads de har i hvert eneste ene program - det er jo årsagen til at deres programmer nærmest fylder uendligt meget. Jeg har undret mig meget over det problem med uret-kalenderen siden før år 2000 hmmmm bliv dog dygtige til at skrive programmer med lidt og effektiv kode frem for at bare fyld på og så spar de forkeret steder så som noget så vigtigt som kalender-ur-tid.
Hvis noget holder op med at virke på grund af fejl fra Microsoft - er man så offer for MS-DoS?
(skynder mig væk)