Alter von Personen berechnen - Fehler im persönlichen Notesadressbuch ?

[udo187]

Hallo

Ich bin gerade beim Erstellen einer Ansicht, die das aktuelle Alter von Mitarbeitern zeigen sollte,
auf die "Problematik"der Altersberechnung gestoßen.

In alten Forumsbeiträgen gibt es verschiedene Lösungen bzw. Hinweise auf die Geburtstagsberechnung im persönlichen Adressbuch.

Hinweis: Aktuelle Datum ist der 27.02.2013

Beim Testen der Formel im persönlichen Adressbuch wird aber das Alter falsch berechnet, wenn das Geburtsdatum
z.B. der 28.02.1973 ist . Richtigerweise müßte als Alter 39 ausgegeben werden, es wird aber mit 40 berechnet.
Bei Eingabe des Geburtsdatum z.B. mit 01.03.1973 wird es korrekt mit 39 berechnet.
Dies passiert auch bei Schaltjahren, z.B. 28.02.1996, das Alter wird mit 17 anstatt 16 berechnet.


Das gleiche Ergebnis ergibt die Formel von Bernhard (http://atnotes.de/index.php/topic,18281.0.html)

_Age1 := @Year (Actdate) - @Year (Birthday);
@If (@Date (@Year (ActDate); @Month (Birthday); @Day (Birthday)) > ActDate; _Age1 - 1; _Age1)


Hat jemand eine Idee warum das Alterfalsch berechnet wird ?

Notesversion 8.5.2 FP2



Danke & Gruß
Udo

[koehlerbv]

Geburtstag: 28.2.1973
Stichtag: 27.2.2013

Bei mir ergibt meine Formel 39. Muss ja auch.

_Age1 := @Year (Actdate) - @Year (Birthday);
Age2 := @If (@Date (@Year (ActDate); @Month (Birthday); @Day (Birthday)) > ActDate; _Age1 - 1; _Age1);

@Prompt ([Ok]; "Age"; @Text (Age2))

Bernhard

[udo187]

hmm - bei mir nicht 

Wird es bei dir im Adressbuch auch korrekt berechnet ?

Udo

[koehlerbv]

1. Sag mal Deine Formel an.
2. Nein.

Bernhard

[udo187]

OK, das ist schon mal gut (bzw. schlecht) dass der Fehler zumindest im Adressbuch nicht nur bei mir auftritt 

Meine Formel:

_AmGeb := AmGeb;

REM {Aktuelles Datum sprachabhängig};
_AktDatum1 := @TextToTime("Heute");
_AktDatum2 := @TextToTime("Today");
_AktDatum := @If(_AktDatum1 > [01.01.1900]; _AktDatum1;_AktDatum2 );

_Alter := @Year (_AktDatum) - @Year (_AmGeb);
_AlterFinal := @If ( @Date ( @Year ( _AktDatum ); @Month( _AmGeb);@Day ( _AmGeb)) > _AktDatum ; _Alter - 1 ; _Alter );
_AlterFinal

[koehlerbv]

Auch "Deine / meine"  Formel ergibt bei mir 39. Du solltest Dir mal genau ausgeben lassen, was die Ergebnisse Deiner _AktDatumx sind.

Folgende Anmerkungen noch:
1) Dieses @TextToTime ('Heute'-in-einer-Sprache) ist aus meiner Sicht sehr kritisch, ich würde das niemals verwenden. Während heute noch jemand kräht, das "wir immer nur deutsche Dominos" haben werden, liegt die Anwendung plötzlich auf dem Domino der japanischen Mutter oder der italienischen Neuerwerbung.

2) Das "Warum" im PersNAB habe ich nicht hinterfragt (ist mir schlicht wurscht). Das wäre mal was für einen langen Winterabend, aber hier im Breisgau soll der Frühling ante portas sein, das wird also wohl erstmal nix   

Ich bin mal gespannt, was Du noch herausbekommst 

Bernhard

[udo187]

Hallo Benhard !

Danke erstmals für Dein Hilfe (aktuell und auch in der Vergangenheit, siehe Deine Formel für die Berechnung des Alters...  ).

Das @TextToTime kritisch ist ist mir bekannt.

Alternativen für tagesaktuelle Ansichten ?? 
 
1.) @Today verwenden (wie IBM in der besagten Ansicht im persönlichen Adressbuch) mit der "fortlaufenden" Aktualisierung der Ansicht ?
2.) @Today verwenden und den Aktualisierungssintervall umstellen auf automatisch, max alle xx Stunden ?
3.) Das aktuelle Datum per periodischen Agent in die Dokumente zu schreiben
-> Replizierung ?

Was würdest Du vorziehen bzw. wie schaut Deine Lösung aus ?

Schönen Abend noch !

Udo

[koehlerbv]

Darauf kann es keine einfache Antwort geben, denn das hängt (wie das meiste i nder Programmierung) davon ab, was man eigentlich erreichen will und wie die Rahmenumstände sind.
Dankbar ist ja auch ein Folder (gefüttert per Agent plus beim Schliessen eines Dokuments mit EditMode = True). Und weiteres ...
Oder: Wenn es hinsichtlich der Dokumentzahl und des Aufbaus der DB im Allgemeinen und der View im Speziellen machbar ist, durchaus auch ein @Today 

Bernhard

[koehlerbv]

Nachtrag:
Embedded single category view - so möglich.

Wichtig: Immer sichestellen, dass dem Nutzer klar ist, ob die View / der Folder auch aktuell sind. So ein Agent könnte ja auch mal ...

Bernhard

[udo187]

Guten Morgen !

So, @TextToTime ist auch nicht das gelbe vom Ei, Index baut sich nicht von selbst neu auf
(wurde bereits in anderen Forumsbeiträgen erwähnt ).
Ich hoffte dass sich die Problematik mit dem Index bei @TextToTime "nur" dann auswirkt wenn es
direkt in der Ansichts-Selektionsformel verwendet wird und nicht wie bei mir in einer Spaltenformel.
Dem ist leider nicht so 

D.h. ich werde um @Today nicht herumkommen...


Was mir eigentlich nicht klar ist, ist der Fehler der Datumsberechnung im persönlichen Adressbuch.

Die hinterlegte Formel lautet:

nowMonth := @Month(@Today);
bdayMonth := @Month(Birthday);
getbday := @If(nowMonth < bdayMonth; (@Year(@Today) - @Year(birthday)) -1;  @Year(@Today) - @Year(birthday));


Warum wird der aktuelle Tag nicht mit dem Tag des Geburtstages verglichen ?
Mit dieser Formel ist man(n) ja sofort ein Jahr älter wenn der aktuelle Monat der gleiche Monat des Geburtstages ist  

Gruß
Udo

[Peter Klett]

...
Was mir eigentlich nicht klar ist, ist der Fehler der Datumsberechnung im persönlichen Adressbuch.

Die hinterlegte Formel lautet:

nowMonth := @Month(@Today);
bdayMonth := @Month(Birthday);
getbday := @If(nowMonth < bdayMonth; (@Year(@Today) - @Year(birthday)) -1;  @Year(@Today) - @Year(birthday));


Warum wird der aktuelle Tag nicht mit dem Tag des Geburtstages verglichen ?
...

Weil das von IBM kommt und die solche Sachen vermutlich nur von Praktikanten machen lassen, die spätestens, nachdem sie angefangen haben, etwas zu verstehen, ausgetauscht werden? 

Aber im Ernst:

Ich würde mir keinen Kopf darüber machen, warum etwas falsch gemacht wurde. Du hast den Fehler gefunden und könntest, wenn Du daran herumschrauben willst (mit allen Nachteilen, die das mit sich bringen kann), das ändern, oder es akzeptieren. Schau Dir mal die Diskussionen hier im Forum über die Qualität der Maildatenbank an.

Aber das ist kein alleiniges Problem von IBM. Es gibt keine fehlerfreie Software, und wird es m.E. auch nie geben können. Bei Notes kann man aber hineinschauen und sehen, wie blöd - oder peinlich - manche Dinge gelöst (bzw. nicht gelöst) wurden (und Du kannst es selbst ändern), das kann man bei Microsoft oder anderen Anbietern so nicht, und die sind alle weit weg von Fehlerfreiheit.

[udo187]

Hallo Peter !

Danke für deine Erläuterung, ich bin auch Deiner Meinung.
Wer frei von Fehler ist werfe den ersten Stein 

Gruß
Udo

[udo187]

Hallo !

Zur Info: Was mir heute bei der oben angegebenen Formel für die Altersberechnung noch aufgefallten ist:
Wenn jemand in einem Schaltjahr am 29.02. Geburtstag hat, wird das Alter im Februar falsch (um 1 Jahr zuviel) berechnet:

z.B. Geburtstag 29.02.1964

@If ( @Date ( @Year ( _AktDatum ); @Month( _AmGeb);@Day ( _AmGeb)) > _AktDatum ; _Alter - 1 ; _Alter );

Weil: @Date(2013;02;29) gibts nicht und gibt daher "" zurück ->
@If gibt dann die zweite Bedingung zurück.


Gruß
Udo

[koehlerbv]

Au weia! Udo, Du hast natürlich vollkommen wahr!

Korrekt(er) wäre die Formel also wie folgt:

Code

_Age1 := @Year (Actdate) - @Year (Birthday);
Age2 := @If (@Adjust (@Date (@Year (ActDate); @Month (Birthday); 1); 0; 0; @Day (Birthday) - 1; 0; 0; 0) > ActDate; _Age1 - 1; _Age1);

@Prompt ([Ok]; "Age"; @Text (Age2))

Das ist auch insofern eine böse Falle, da Datenumber (2013, 2, 29) liefert hingegen (korrekt) den 01.03.2013.

Bernhard

[udo187]

ja, und dieser kleine "Fehler" ist mir auch nur aufgefallen weil ich auch einen Export mittels Skript durchführe und beim "zufälligen" Vergleich der Ansicht und des Exportes hatte ich eine Differenz von einem Jahr. (weil Datenumber eben korrekt rechnet)...

Bist Du heuer wieder beim Entwicklercamp vertreten ?

LG
Udo

[koehlerbv]

Nein, dieses Jahr geht es sich nicht aus bei mir. Dafür ist mein Kollege und "Raumteiler" Torsten "Tode" Link als Referent anwesend. Das ist ein mehr als würdiger Personaltausch (hoffentlich akzeptiert mich Rudi danach noch mal als Referent aus unserem Hause ...).

Bernhard