Zie ook: https://borncity.com/win/2022/01/02/microsoft-besttigt-exchange-year-2022-problem-fip-fs-scan-engine-failed-to-load-1-jan-2022/ en https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-exchange-on-premises-transport-queues/ba-p/3049447

Gaat nog wat worden in 2038 .....

In applicaties is het verstandig om gebruik te maken van ISO-8601 voor date-timestamps.

Bijna alle software libraries ondersteunen ISO-8601 format, en dit maakt import/export van data gemakkelijk.

Het lijkt eerder een marketingstrategie: net zolang problemen en ellende in een product inbouwen totdat iedereen het heeft laten vallen en naar Exchange Online over is.

Ik dacht dat ze daar al in 1999 hier serieus aan gewerkt hadden, maar kennelijk hebben die programmeurs dat probleem nog niet onderkent. Wederom een heel goede reden om MS de deur uit te gaan doen.

De oplossing die ze 21 jaar gelden bedacht hadden is nu weer achterhaald :-)
En de volgende oplossing weer in 2043.
Etc, etc, etc

Inderdaad, dat was ook de reden, dat Windows-98 gereset moest worden, omdat de up-time werd bijgehouden als 32bits getal, deze kon dan ook niet een week non-stop werken.
Werd het getal groter dan 32 bits, dan crashte Windows-98.
Leren uit het verleden en fouten onthouden is blijkbaar lastig.......... :-)

Ik zou voor RFC3339 (https://www.rfc-editor.org/rfc/rfc3339) gaan. Beter nog, gebruik een formaat dat door beide standaarden wordt geaccepteerd.

Het probleem is dat men (zoals zo vaak bij dat bedrijf) geprobeerd heeft om met een "slim gekozen format" (het jaar
maar als 2 cijfers ipv 4 en dan nauwkeurigheid tot op 1 minuut) het voor elkaar gekregen heeft om een timestamp in
8 cijfers te proppen, terwijl men dat dan ook nog eens als een binaire waarde wilde gaan verwerken.

Was er gekozen voor YYYYMMDDHH dan was het voorlopig niet fout gegaan. Maar 1 uur resolutie vond iemand
kennelijk niet goed genoeg. Dus werd het compromis YYMMDDHHMM gekozen. Alsof Y2K nooit bestaan heeft.
Dit gecombineerd met signed waarden breekt hen nu op.

Kijk ze hadden ook YYYYMMDDHHMMSS kunnen gebruiken en dan een 64-bit variabele. Die mag dan zelfs signed
zijn. Afijn genoeg goede oplossingen.

Of Epochalypse... Dat is al 2 jaar eerder en als je ziet hoeveel legacy daar nu nog mee draait.

https://en.wikipedia.org/wiki/Year_2038_problem

Je bedoelt onderkend, maar dat terzijde.

Exchange is er al sinds 1996, maar van wanneer de FIPS-FS Scanner Engine is is mij niet duidelijk. Ik vermoed dat het datumveld waar het om gaat pas na de eeuwwisseling in gebruik is genomen, want negatieve getallen inzetten bij een binair getal dat in decimale weergave overeenkomt met een datum is wel erg omslachtig.

Mij zou het niet verbazen als het ver na 2000 is gebouwd door programmeurs die te jong zijn om het Y2K-probleem zelf bewust te hebben meegemaakt, en die door gebrek aan die ervaring een soortgelijke fout hebben gemaakt.

Is er hier iemand die weet wanneer de FIPS-FS Scanner Engine voor het eerst is uitgekomen?

Het grote probleem van MS is dat zij zo'n grote blobs maken. Waar stond Microsoft oorspronkelijk ook voor? "Micro" "soft", dus micro software. Daar zijn zij al heel lang geleden vanaf gestapt. Als zij de UNIX filosofie hadden geimplemtenteerd dan hadden zij waarschijnlijk iets meer moeten gaan doen in hun documentatie, maar hadden zij hun code veel beter kunnen controleren en waarschijnlijker ook een veel veiliger systeem op kunnen zetten. Dat hebben die briljante gasten dus niet gedaan en nu zitten jullie met de problemen. Veel succes allemaal.

Wie zei dat ook alweer? "Succes is een keuze"

Het zal eerder bedoeld zijn geweest als software voor microcomputers. In die tijd was een indeling in mainframes, minicomputers en microcomputers gangbaar. De huidige pc's en servers waar Windows op draait zijn nog altijd een doorontwikkeling van wat destijds onder microcomputers viel.

Het lijkt misschien een datumprobleem, maar dat is het niet. Vooral niet als je kijkt naar e oplossing die Microsoft nu voor de korte termijn gekozen heeft. Ze zijn de malware-definities gewoon gaan doornumeren.
Dus de eerstvolgende werkende versie na 1-1-2022 werd 2112330001. Als dit een datum zou zijn, dan is het dus 33 december.

Lijkt gewoon op een onhandig gekozen versienummer-systeem, of nog waarschijnlijker werd de integer gecompileerd naar een int32 terwijl er een aanname werd gedaan dat op een 64-bitsysteem het een int64 zou zijn en dus nooit een probleem had mogen opleveren.

Gewoon knullig. Hieraan vertrouw je een essentiële communicatiedienst toe.

Dit heeft niet zoveel met Unix filosofie te maken. Dit is gewoon knullig coderen van de bovenste plank. Controleren en testen is behoorlijk weggezakt bij MS. Teveel focus op cloud.

Ja Als je een representatie systeem verzint, kijk je toch ook wat het grootste en kleinste getal is wat er in past? Een signed integer kan natuurlijk voor een datum, want je wilt misschien ook een datum van voor het nulpunt kunnen weergeven. (Hoewel zulke oude mail natuurlijk niet zal bestaan)

Toen ik in de jaren 80 leerde rekenen op computers, werd ons er al op gewezen dat de volgorde van bewerken, uitmaakte op de uitkomst. Dit vanwege de begrensde opslaglengte van getallen. Als programmeur moet je daar altijd rekening mee houden.

Het was een datumprobleem omdat in die versienummers een datum verwerkt was en dat in een veld belandde waar dat niet meer in paste. Dat men het heeft opgelost door te stoppen het als datum te interpreteren wil niet zeggen dat dat het probleem niet was. Dat was het wel, er werd binnen een veld een codering gebruikt met een datum erin die vanaf 2022 niet meer past. Dan is het volkomen terecht om het een datumprobleem te noemen.

Vergeet de bashers, die herkennen het probleem niet als de code voor ze open en bloot ligt.
Van voor 2013 zijn er geen hits te vinden.
https://social.technet.microsoft.com/Forums/en-US/4b6293a3-0c2c-4299-b1fd-55d732586904/exchange-transport-filtering-management-services-throttling-fail-to-start?forum=exchangesvrgeneral
Ik zie andere hints dat het vanaf 2013 geintegreerd werd.

Duidt op een eerdere overname. deze zou dat kunnen zijn: https://news.microsoft.com/2005/06/21/sybari-and-microsoft-delivering-enterprise-security-value-through-integration-and-collaboration/

Je beschrijft een klassiek bufferoverflow probleem. Met een conversie (gebruik geen is8601 strings intern!) moet je met een bereik rekening houden. Niets bijzonders en er lijkt zeer snel een oplossing voor te zijn.
Gevolg van Agile werken waarbij ontwerp niet relevant is als het maar werkt. Zeer bekend als open source aanpak

Klopt. Microsoft ontwikkelde in die tijd ook voor IBM. Ze werden betaald per KLOC (1000 regels code). Die cultuur (more is more) zal ook wel hun eigen producten beinvloed hebben.

Nee, dit is geen buffer overflow. Dit is een conversie van vermoedelijk een string naar een 32-bit integer die stukloopt omdat de waarde niet in de integer past. Dat is iets wezenlijk anders dan het corrumperen van de inhoud van geheugen dat aan een buffer grenst omdat de grenzen van de buffer niet worden bewaakt. De berekeningen van de conversie worden in CPU-registers uitgevoerd, de buffer en het aangrenzende geheugen staan in RAM. Het komt niet in de buurt van hetzelfde probleem zijn.

Je kan onmogelijk weten of dat hier het geval is. Dit soort fouten werd bij waterval-ontwikkelmodellen als SDM net zo goed gemaakt.
Grappig hoe vaak je die opmerking plaatst als er iets in closed source misgaat. Alsof je iets aan probeert te vallen met argumenten die je niet hebt.

Agile is een familie van werkwijzen voor ontwikkelteams in bedrijven en organisaties. Menig open source-project zal bijvoorbeeld geen boodschap hebben aan timeboxing om de kosten en voortgang voorspelbaar te houden, daar is juist veel vrijheid om het tempo aan te houden dat nodig is om een feature te realiseren. Een dagelijks, staande scrum-bijeenkomst van maximaal een kwartier is ook vrij lastig als de ontwikkelaars helemaal niet op dezelfde plaats en tijd werken aan het project. Agile is vooral bekend als closed source-aanpak, als je het mij vraagt.

Datumproblemen zijn niets nieuws.

Op 5 t/m 14 oktober 1582 hadden zo ook een aardig probleem.
(Check je kalender maar eens).

Dat is een beetje misleidend.

"We" zijn toen overgestapt van de Juliaanse naar de Gregoriaanse kalender. En beiden kenden een andere berekening om bij het startpunt te komen. Vandaar dat die dagen die je noemt "verdwenen".
Anders gezegd: Na 5 oktober 1582 kwam als volgende dag 14 oktober 1582.

Zulk soort problemen ontstaan ook als bv de Joodse kalender door de Juliaanse kalender vervangen zou worden. oid (zoek ook maar op)

Het MS probleem heeft te maken met de opslag van de datum in een integer.
En dat past niet meer. IMHO luiheid van de toenmalige programemeurs (in het verlengde van "64k is voldoende voor alle gebruikers").

Er zijn vanwege de invoering van de Gregoriaanse kalender tien dagen vervallen: op 4 oktober volgde 15 oktober.

We zitten nu toch al opgescheept met een door Romeinse keizers verpeste kalender die 2 maanden opgeschoven is
waardoor je die rare situatie krijgt dat "september" de 9e maand is enz. (sept = 7), en de extra schrikkeldag in het
jaar zelf valt in plaats van helemaal aan het eind (als Maart de 1e maand was en Februari de laatste was dat handiger)

Nog beter zou het zijn als nieuwjaar op 21 maart zou vallen, of in ieder geval op het begin van de lente.
En een wat handiger maandindeling zou ook niet weg zijn.
Maar ja, ijdelheid en religie hebben het gewonnen van rationaliteit.

Je mag in de achterhoede gaan lobbyen voor een nieuwe revolutie .
Het is al eens geprobeerd :

https://nl.wikipedia.org/wiki/Franse_republikeinse_kalender

En nog een kleine oplevering

https://en.wikipedia.org/wiki/Swatch_Internet_Time

De werkelijkheid is rommelig, ja.

Ik zie het meer als de hardnekkigheid van gewoontes, versterkt doordat allerlei werkwijzen en systemen die gewoontes hebben geïntegreerd. Kijk bijvoorbeeld naar hoe moeilijk het is om het onderscheid tussen zomer- en wintertijd weer af te schaffen. Dat heeft niets met religie of ijdelheid te maken, en alles met weerstand tegen veranderen waar men aan gewend is.

Wat jij beschrijft is hoe moeilijk het is om er nu nog vanaf te komen. Wat ik bedoel is de manier waarop dit tot stand
is gekomen.

Zeg maar rustig: Politici die geen keus kunnen en willen maken?
Wat ze ook kiezen, ze hebben het altijd gedaan. Dus stellen ze een keuze uit.

De Europese Commissie legde de hete aanrdappel bij de landelijke regeringen. Die keken elkaar weer aan, want ze willen weer niet teveel van elkaar afwijken. En hun burgers en bedrijven hebben verschillende wensen of belangen.
Dan is de politieke kop in het zand steken, het veiligste.

En ik wordt nu al weer ruim 3 maanden voor 5 uur in de ochtend klaar wakker.
Lang leve een constante biologische klok die geen rekening houdt met een verzonnen zomer- of wintertijd.

Je noemde iets dat je beter zou vinden dan nu gebruikt wordt of ooit gebruikt is, en gooide je "maar ja"-opmerking over ijdelheid en religie direct daarachteraan. Dan is een reactie over weerstand tegen verandering niet zo vreemd, hoor. Ik reageerde kennelijk niet op wat je bedoelde, maar volgens mij wel op wat je schreef. ;-)