Voor StUF geldt de eis dat ieder ingezonden bericht van dezelfde afzender een uniek tijdstip heeft. Nu het berichtenverkeer steeds intensiever wordt met een groot aantal berichten per seconde, gaat deze eis botsen met het formaat van Tijdstip. Tijdstip kent slecht drie posities per seconde (duizendsten van een seconden). Gezien het toenemend berichtenverkeer is het voorstel om daar minstens vier posities aan toe te voegen, dus [0,9]{8-21} in plaats van [0,9]{8-17}
do, 4-12-2014 - 19.50u
#1
StUF:Tijdstip onvoldoende nauwkeurig bij intensief berichtenverkeer
Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0357.
De lijst met onderhoudsverzoeken vind je op:
https://gemmaonline.nl/images/cocreatiebasisgemeente/0/0e/Onderhoudsv...
De StUF-standaard schrijft ook voor dat het tijdstip bericht altijd groter moet zijn dan het voorgaande tijdstipBericht. Zonodig moet je tijdstipBericht dus vooruit laten lopen op het werkelijke tijdstip waarop het bericht wordt gecreëerd. Ik ken geen situaties waar dit vooruit lopen uiteindelijk oploopt tot uren. Je moet dan bijvoorbeeld 7.2 miljoen berichten creëren binnen een uur. Het lijkt me derhalve verstandig om dit pas mee te nemen in een volgende versie van StUF.
Dit issue is besproken tijdens de StUF Expertgroep van 17 december 2014.
Er is toen geconstateerd dat zelfs met het toevoegen van extra decimalen je tegen dit probleem aan zou kunnen lopen. Het handelt hier in ieder geval om een RFC en het wordt nu dus hoe dan ook niet opgelost. Het gaat hier ook niet om volume maar om de toevalligheid dat een bericht een zelfde timestamp heeft als een ander bericht van dezelfde afzender.
Er is geconcludeert dat dit probleem technisch heel simpel op te lossen is en dat dit door de leverancier in de software moet worden opgelost.
De StUF Expertgroep vindt het geen zinnige RFC en het onderhoudsverzoek wordt dan ook afgevoerd.