rekenen met datums

[masja]

Hallo allemaal,

 

Ik ben inmiddels lekker op dreef met Filemaker en ik kan er aardig mijn weg in vinden.

 

Ben nu bezig met een klein planningsprogrammaatje en ik loop tegen de volgende vraag aan:

 

Als ik een datum 4 maanden of 3 weken wil opschuiven moet ik dan 4/12*365 of 3/52*365 bij de oorspronkelijke datum optellen of kun je ook met maanden en weken tellen?

 

In mijn voorbeeldje zit je altijd met afrondings fouten omdat niet elke maand evenveel dagen heeft en je ook met schrikkeljaren te maken hebt.

 

Alvast bedankt voor eventuele suggesties

Masja

[Rony Rabijns]

Masja,

 

4 maanden later dan de maand van datum is Month(datum) + 4.

3 weken (=21 dagen) later dan de dag van datum is Day(datum) + 21.

 

De nieuwe datum maak je dan met de Date()-functie, die je vult met de nieuw berekende waardes zoals hierboven.

[masja]

Bedankt voor je snelle reactie Rony!

 

Volgens mij kom ik er op deze manier wel uit. Ik vraag me alleen nog af hoe ik om moet gaan als ik met het verhogen van de datum in het volgende jaar terecht kom.

 

Moet ik dan eerst lberekenen of de maand > 12 wordt en zo ja dan het jaar verhogen en het verhogen van de maanden splitsen over de twee jaren?

[Rony Rabijns]

Masja,

 

Filemaker is heel slim en rekent verder indien de dag of maand hoger liggen dan toegestaan.

 

Zie voorbeeldje.

Datum.fp7

[masja]

Volgens mij ben jij ook heel slim

 

Bedankt voor de hulp!

[JeanWM]

 

Filemaker is heel slim en rekent verder indien de dag of maand hoger liggen dan toegestaan.

 

 

... en komt dan weer omdat FileMaker niet met dag, maand, jaar werkt, maar met nummers.

 

Copy een datumveld en maak er type number van, dan zie je de achterliggende data waar FileMaker mee werkt.

 

Met die wetenschap is het dan niet moeilijk om je datumberekeningen te begrijpen.

[Jeroen Aarts]

... en komt dan weer omdat FileMaker niet met dag, maand, jaar werkt, maar met nummers.

FileMaker zet een datum om in het aantal dagen sinds 1/1/0001, dit is dan inderdaad een nummer.

 

Door bijvoorbeeld GetAsNumber(Get(CurrentDate)) in te voeren in een berekend veld of in de dataviewer, merk je dat er sinds 1 januari van het jaar 1 al 733025 dagen voorbij zijn gegaan. Best wel veel eigenlijk hee.

[JeanWM]

En 'tijd' werkt zowat volgens hetzelfde principe maar dan op 24 uur basis.

 

Velponiseer je datum en tijd aan mekaar dan stamp je een andere informatie uit FileMaker, daarom noemen ze dat Timestamp.

[AvD]

't Zit hier blijkbaar vol met charmante en zeer behulpzame heren. Kan ook niet anders...

 

Als je dan echt alles zou willen weten, dan is er nog het "0, 1900, 1904 en 1970"-mysterie, waar we ooit uitgeraakt zijn dank zij Murtje en G. zelf:

Als toemaatje nog dit: FileMaker onthoudt een datum als een getal, namelijk het aantal dagen verlopen sinds een vast beginpunt. Dat beginpunt ligt voor Windows op 1 januari 1900. Dag 31 is dus 31 januari 1900 en dag 32 is 1 februari 1900. Het systeem werkt ook met decimalen: dag 32,5 is 1 februari 1900 om 12 u 's middags en dag 32,75 is 1 februari 1900 om zes uur 's avonds. Natuurlijk gebeurt dit allemaal op de achtergrond. FileMaker toont ons wel dit getal indien we een datum als Number laten zien. Het werken met dit systeem gebeurt voor ons gelukkig op de achtergrond en we merken niet eens dat er vier verschillende systemen in omloop zijn (dank aan Peter):

 

- Windows: telling vanaf 1-1-1900

 

- MacOS tot 9: telling vanaf 1-1-1904 (er doen verhalen de ronde over de reden*)

 

- MacOS X: telling vanaf 1-1-1970 (zoals bij Unix)

 

- FileMaker Pro: telling vanaf 1-1-0001

 

Met dank aan Murtje en Peter Wagemans

Het geheel staat nog eens uitgelegd op deze plek.

[Koen Van Hulle]

Pas toch goed op bij planningssystemen met het begrip "we schuiven dit een maandje op". Want wat is een maandje?

 

Als we donderdag 6 december 2007, letterlijk een maand opschuiven, dan zal dit op schuiven naar 6 januari wat op een zondag valt.

De vraag is wil je dat wel.

 

Ook de methode met één maandje bedoelen we 4 weken, zou niet altijd de juiste kunnen zijn. Er zijn immers ook maanden van 5 weken.

 

Er is dus bijvoorbeeld een hemelsbreed verschil tussen een cyclus van "2 maal in de maand" en de cyclus "om de 14 dagen".

 

Een andere definitie van een maandje opschuiven zou kunnen zijn de x-de weekdag van de maand.

 

6 december is de 1 donderdag van de maand, dus de volgende maand zal donderdag 3 januari zijn.

 

Bij deze methode moet je ook oppassen, de eerste vrijdag van de maand, kan voor de eerste maandag van de maand vallen.

 

Bij een planningssysteem hangt het er vooral vanaf wat de definitie van "een maand opschuiven" precies wil zeggen.

 

 

Koen

[masja]

Hallo allemaal,

 

Het is goed toeven op dit forum! Nuttige tips doorspekt met de nodige humor. Behalve voor het opvijzelen van je kennis kun je hier ook nog je vocabulaire ophalen (velponiseren )

 

Als beginnend 'vragertje' voel je je snel bezwaard om weer eens wat te vragen. Het moet immers wel van twee kanten komen.

 

Ik ga daarom proberen een creatieve bijdrage te leveren aan de 'community'. Technisch gezien hoeven jullie er niet veel van te verwachten. Daar hebben we de Guru's en de tovenaars voor. Mijn inbreng zal meer bestaan uit ideetjes die jullie waarschijnlijk al lang zelf bedacht hebben maar misschien ook niet.

 

Hier komt de eerste dan...

 

Filemaker is behoorlijk layout georienteerd terwijl het beheren van de layouts zachtgezegd matig is. Je kunt wel een eerste letter intypen waardoor hij naar een layout met die beginletter springt maar ideaal is het niet. Daarnaast moet je met heen en weer schuiven een beetje structuur in de zaak zien te krijgen.

 

Daarom mijn ideetje voor een layoutoverzicht waarmee je kunt zoeken naar een layout, op alfabet kunt sorteren en direct naar de layout kunt jumpen. Als er ideeen van jullie kant zijn om dit nog verder te verfijnen dan hoor ik ze graag!

 

Groeten

Masja

layoutoverzicht.fp7

[Koen Van Hulle]

Leuk scriptje.

 

Kijk ook even naar de "Design Functions" in FileMaker.

 

LayoutNames ( Get(FileName) )

 

Geeft bijvoorbeeld alle layouts in een bepaald bestand terug.

Bekijk het lijstje van functies goed, er zitten een paar leuke bij.

 

 

 

Koen

[AvD]

Als beginnend 'vragertje' voel je je snel bezwaard om weer eens wat te vragen. Het moet immers wel van twee kanten komen.

Er zijn wel een paar regels op een forum, maar deze staat er niet bij. Lutgard zei het al in de 70'er jaren: "Vragen staat vrij".

[Rony Rabijns]

"Vragen staat vrij".

 

En antwoorden ook

[WJ]

Leuk scriptje.

 

Kijk ook even naar de "Design Functions" in FileMaker.

 

LayoutNames ( Get(FileName) )

 

Geeft bijvoorbeeld alle layouts in een bepaald bestand terug.

Bekijk het lijstje van functies goed, er zitten een paar leuke bij.

 

 

 

Koen

 

Hoi koen,

 

Inderdaad leuk script gebruik het met plezier, bedankt!

De laatste scriptstap Halt script gebruik omdat.... (voorals er een ander script loopt ?)

 

Groet

[Captain Haddock]

Kijk ook even naar de "Design Functions" in FileMaker.

 

LayoutNames ( Get(FileName) )

 

'k Ben net in een ander verband bezig layouts te organiseren en wat mij nu opvalt is dat er behalve de geciteerde functie wel een LayoutIDs() bestaat en een Get(LayoutNumber), maar geen Get(LayoutID).

 

't Verschil is dat layoutnummers zeer relatief zijn - ze hebben betrekking op de layout order - terwijl de layoutid's zo te zien aangemaakt worden op het moment van creatie.

 

Ik ben nu veroordeeld tot het gebruik van de layoutnames, die hernoemd kunnen worden en zelfs niet uniek hoeven zijn, maar toch minder relatief zijn dan de nummers!!

 

Zo kwam ik op een beheersachtige constructie, die ook weinig zoden aan de dijk zet omdat 'new layout' niet te scripten is en je dus geen zicht hebt op wat er 'binnenkomt'.

 

Nou ja, hopen maar op Filemaker 10 dan?

[JeanWM]

Je kunt toch de layoutnummers gebruiken om een dynamische referentie te maken ?

Hiermee kun je je scripts gaan branchen, de referentie blijft bestaan.

 

Je mag dan zo dikwijls als je wil de layoutnaam veranderen of layouts toevoegen/verwijderen, de volgorde veranderen, de referentie zal blijven bestaan en dynamisch mee veranderen als het moet.

[Captain Haddock]

Hoe zie je dat precies Jean, je moet toch hoe je 't wendt of keert per layout een onveranderlijke waarde hebben om naar te verwijzen?

[JeanWM]

Die waarde moet altijd verwijzen naar de juiste layout.

 

De naam van de layout kun je wijzigen, is niet bruikbaar.

De volgorde van layouts kun je wijzigen, dus Get(LayoutNumber) is ook niet bruikbaar.

 

We moeten dus een manier hebben om, zelfs indien we de naam veranderen en/of de volgorde veranderen, we toch nog naar de juiste layout blijven verwijzen.

 

Dat kan met bijvoorbeeld een unstored calculation, result text:

 

MiddleWords(LayoutIDs(Get(FileName)); Get(LayoutNumber); 1)

 

Het resultaat kun je gebruiken in scripts als referentie naar een layout.

Je mag de volgorde veranderen, de naam veranderen, zelfs een clone maken, de referentie zal blijven, onafgezien welke verandering je aanbrengt.

Je moet enkel zorgen dat het berekeningsveld aanwezig is voor je met de rest van de toepassing verder gaat.

[Captain Haddock]

...want de layoutIDs staan altijd in de layout order. Ik vat 'm.

 

Geweldig!

 

Ik gebruik wel MiddleValues ipv MiddleWords, want anders heb je de poppen aan 't dansen als iemand een spatie gebruikt in een layoutnaam.

 

Bedankt Jean

[JeanWM]

Ik gebruik wel MiddleValues ipv MiddleWords, want anders heb je de poppen aan 't dansen als iemand een spatie gebruikt in een layoutnaam.

 

 

Dan werk je buiten conventie.

Maar eigenlijk mag je zoveel spaties gebruiken als je wil, de code zal in principe niet breken.

[JeanWM]

Voorbeeld van layout name zonder spaties en layout name met spaties en verplaatst.

 

De layouts behouden hun ID. (5 en 13)

[Captain Haddock]

Je hebt gelijk, die functie betreft de id's en niet de layoutnames.

[JeanWM]

Exactamente, muy bien ¡ !