dagen optellen

hallo ik wil met een arduino nano en een ds3132 etc op een lcd scherm.
kunnen zien hoeveel dagen er sinds een vast gestelde datum zijn verstreken zijn.
wie zou mij kunnen helpen dit te realiseren?
graag hulp of advies hoe dit te doen.

Beide datums opslaan als unix timestamp, van elkaar aftrekken en weer naar datum converteren of verschil berekenen.
Hoe dat met arduino gaat weet ik niet (welke functies er beschikbaar zijn), ik doe (gelukkig :) ) niets daarmee...

Waarom je dit niet zelf wilt maken: https://github.com/kdeldycke/awesome-falsehood#dates-and-time

Ik zou gaan voor een library.

EDIT: heel de discussie hieronder bevestigd dat nog maar eens. :)

[Bericht gewijzigd door hardbass op (21%)]

Zie header file time.h en https://www.nongnu.org/avr-libc/user-manual/group__avr__time.html

- Eerst een structure (struct tm) vullen met uren minuten seconden jaar maand dag.

- Dan omrekenen naar een time_t dmv mktime()

 time_t mktime(struct tm *x);

- En met die time_t kun je rekenen. Dat is een integer met aantal seconden sinds 1 jan 2000 (was vroeger 1970 maar is blijkbaar veranderd).

PS: Dit is onderdeel van de standaard C library die met de compiler meekomt.

Op 29 september 2023 16:19:43 schreef deKees:
[...]
- En met die time_t kun je rekenen. Dat is een integer met aantal seconden sinds 1 jan 2000 (was vroeger 1970 maar is blijkbaar veranderd).
[...]

Sinds wanneer is dat 2000 geworden? https://www.unixtimestamp.com/ houdt het nog steeds op 1970. Deze idem.

1695719136

Dit is de UTC timestamp die ik van een node terug krijg als ik opvraag wanneer de node voor het laatst water heeft bijgevuld. Wat dinsdag 26 september geeft om 9:05:36 UTC.

Heb je een verwijzing naar 2000?

Sinds wanneer is dat 2000 geworden?

Ik zou het niet weten. Misschien alleen voor AVR?
Zie https://www.nongnu.org/avr-libc/user-manual/group__avr__time.html#ga33…

Moet het persé op een arduino nano en met een ds3132, of is het zomaar een suggestie en is het doel (weergave van aantal dagen) belangrijker en sta je open voor een andere (wellicht eenvoudigere) aanpak?

Op 29 september 2023 22:30:31 schreef deKees:
[...]

Ik zou het niet weten. Misschien alleen voor AVR?
Zie https://www.nongnu.org/avr-libc/user-manual/group__avr__time.html#ga33…

Hmm. Inderdaad. Dit verschil met de "standaard" unix timestamp is niet fijn. Stel TS wil laten zien hoe oud iemand is in dagen... Formeel kan de geboortedatum dan niet in de time_t.

Unix timestamp is nog steeds gebaseerd op 1970. Volgens mij zijn ze ondertussen hard onderweg om de boel 64 bits te maken, zodat je van oorsprong der tijden tot halverwege "heat death of the universe" kan representeren (*).

(*) Bij wijze van spreken.

Op 29 september 2023 22:17:59 schreef buckfast_beekeeper:
Sinds wanneer is dat 2000 geworden?

RTFM:

Though not specified in the standard, it is often expected that time_t is a signed integer representing an offset in seconds from Midnight Jan 1 1970... i.e. 'Unix time'. This implementation uses an unsigned 32 bit integer offset from Midnight Jan 1 2000. The use of this 'epoch' helps to simplify the conversion functions, while the 32 bit value allows time to be properly represented until Tue Feb 7 06:28:15 2136 UTC. The macros UNIX_OFFSET and NTP_OFFSET are defined to assist in converting to and from Unix and NTP time stamps.

Ik heb de standaard niet gecontroleerd, maar als klopt wat hier staat is het nooit 1970 geweest, of althans, is 1970 eigenlijk toeval geweest :-)

Voor communicatie tussen verschillende systemen of logs is een unix-timestamp sowieso niet geschikt. Naast het feit dat windows, NTP, excel allemaal andere epochs gebruiken is ie maar tot 2038 houdbaar, en ontbreekt tijdzone informatie

Een unambigue representatie als 20220930:110535+0200 is dan veel duidelijker

De meeste Unix systemen hebben de epoch timestamp inmiddels uitgebreid naar minimaal 33 bits (ja klinkt lekker, 1 bit extra, maar schopt het probleem een flink eind vooruit)

Op 29 september 2023 22:30:31 schreef deKees:
[...]

Ik zou het niet weten. Misschien alleen voor AVR?
Zie https://www.nongnu.org/avr-libc/user-manual/group__avr__time.html#ga33…

Nochtans wordt dit door een ATmel644P met RTC DS3231 (geen DS3132) uitgebraakt.

Op 30 september 2023 11:07:04 schreef blurp:
[...]

RTFM:
[...]

Ik heb de standaard niet gecontroleerd, maar als klopt wat hier staat is het nooit 1970 geweest, of althans, is 1970 eigenlijk toeval geweest :-)

Voor communicatie tussen verschillende systemen of logs is een unix-timestamp sowieso niet geschikt. Naast het feit dat windows, NTP, excel allemaal andere epochs gebruiken is ie maar tot 2038 houdbaar, en ontbreekt tijdzone informatie

Een unambigue representatie als 20220930:110535+0200 is dan veel duidelijker

Zend ik de UNIX timestamp naar een MariaDB, dan gaat die toch ook wel de correcte tijd weergeven. Zo abnormaal is die UNIX tijd dus niet. De Excel tijd is dan toch wel een stuk onhandiger.

2038? Dan ben ik ruim de 70 voorbij. De kans dat ik dan niet eens meer aan tijd a of b denk is vrij reëel. Tegen dat we zover zijn wordt er wel een oplossing gevonden en vinden we 32 bits iets uit de oude doos. Een byte meer of minder gaat het verschil niet meer maken.

Tegenwoordig wordt op 64 bits Unix systemen ook een 64 bits teller gebruikt. Voordat die overflowed dan bestaat de aarde waarschijnlijk ook niet meer.

Alleen embedded 32-bits (linux) systemen gebruiken vaak nog de 32-bit representatie (signed dus eigenlijk 31 bits).

In die AVR libc zitten trouwens 2 constantes om de 2k epoch om te rekenen naar bijvoorbeeld unix tijd (1970 dus). Lekker onhandig dat er niet in het commentaar bij staat hoe dan die specifieke epoch telt. (UNIX_OFFSET en NTP_OFFSET)

Zowiezo is rekenen met tijden echt een complete nachtmerrie. Zoals @hardbass ook al zegt, niet zelf proberen als je een fatsoenlijke library hebt.

Op 29 september 2023 23:02:41 schreef OPTOdesign:
Moet het persé op een arduino nano en met een ds3132, of is het zomaar een suggestie en is het doel (weergave van aantal dagen) belangrijker en sta je open voor een andere (wellicht eenvoudigere) aanpak?

Ik sta zeker open voor een andere oplossing ik zou graag horen hoe?

Op een Windows PC is het simpel...

Op 30 september 2023 11:07:04 schreef blurp:
Ik heb de standaard niet gecontroleerd, maar als klopt wat hier staat is het nooit 1970 geweest, of althans, is 1970 eigenlijk toeval geweest :-)

Het is van midden jaren zeventig dat Unix werd uitgevonden tot ergens begin deze eeuw ALTIJD zo geweest dat die timestamp op 1970 gebaseerd was. Sinds ongeveer de eeuwwisseling is men standaarden gaan schrijven. En kennelijk heeft dan de eerste opgeschreven standaard zich niet uitgelaten over het startpunt. Kan allemaal best, maar als het 30 jaar zo IS dan IS het gewoon "de standaard".

Stel ik maak REWIX en gebruik die arduino-implementatie. En ik roep dat het gewoon POSIX compatible is omdat "de standaard" toestaat dat ik een ander "epoch" gebruik. Jij mag alle programmas die dan niet werken gaan uitleggen dat ZIJ het fout hebben gedaan en dat MIJN implementatie gewoon volgens de standaard is. Goed? Deal?

De windows timestamp telt vanaf 1-1-1601 en is altijd 64 bit geweest (met 100ns resolutie), dus geen problemen... ;)

Op 30 september 2023 22:38:54 schreef olan:
[...]

Ik sta zeker open voor een andere oplossing ik zou graag horen hoe?

Er zijn vele oplossingen denkbaar waarbij Arco de meest eenvoudige oplossing geeft die, als je een computer met Windows hebt snel gerealiseerd kan worden; al dan niet op een extra (extern) scherm. Bijvoorbeeld met Microsoft Powerpoint (grafische gedeelte) en VBA (teller gedeelte). Maar je wilt waarschijnlijk je computer niet opofferen als het stand-alone moet werken.

Dan is het handig op wat specifieker te zijn over je wensen en eisen:

  1. Wat is je doel? Waarvoor is het?
  2. Hoe groot wordt het getal dat je wilt tonen (praten we over enkele millimeters of meerdere centimeters)?
  3. 'een vast gestelde datum' > Is dit een vaste datum die je vooraf eenmalig programmeert of wil je deze dagelijks/wekelijks/maandelijks/jaarlijks aanpassen?
  4. Wat is je budget?
  5. Waar moeten we nog meer rekening mee houden om met je mee te denken?

'Aantal dagen' is ook een rekbaar begrip wat voor meerdere uitleg vatbaar is...

Je kunt zuiver de dagen tellen. (tussen dinsdag 23:59 en donderdag 00:01 zitten dan 2 dagen)
Je kunt het aantal uren / 24 tellen. (tussen dinsdag 23:59 en donderdag 00:01 zit dan maar 1 dag...)

Hoe groot wordt het getal dat je wilt tonen (praten we over enkele millimeters of meerdere centimeters)?

Ik weet dat ze het soms over 'de lengte van dagen' hebben, maar da's meestal niet in centi/millimeters... :)

Wat ik wil is een lcd scherm 2 x 16 inbouwen in een doosje met transparant deksel.
Een vaste datum laten we zeggen nu , het geheel aan en uit zetten met schakelaar.
En steeds aangeven hoeveel dagen er zijn verstreken sinds nu dus.
Vast gestelde datum verandert niet, en laten we zeggen een jaar.

Het is voor een collega die ons verlaat.

Aha. Het betreft dus een 'gadget' met een 2x16 karakter display. Dat is vrij eenvoudig te realiseren met een simpele microcontroller. Het doet mij denken aan les 4 van deze website. Er zijn ook vele voorbeelden en opzetjes te vinden met een arduino nano.

Het blijft wat mij betreft nog wat vaag wat precies je hulpvraag is en wat je zelf tot nu toe voor elkaar hebt - waar loop je vast?

Edit: Ik kwam dit topic tegen waaruit blijkt dat je eerder al eens met een 2x16 display hebt gewerkt.
Probeer zo duidelijk mogelijk te zijn in welk stadium je project zich bevindt, toon je code en waar je tegenaan loopt. Dan kunnen we je zeker effectief helpen!

[Bericht gewijzigd door OPTOdesign op (23%)]

Op 1 oktober 2023 13:09:20 schreef rew:
Stel ik maak REWIX en gebruik die arduino-implementatie. En ik roep dat het gewoon POSIX compatible is omdat "de standaard" toestaat dat ik een ander "epoch" gebruik. Jij mag alle programmas die dan niet werken gaan uitleggen dat ZIJ het fout hebben gedaan en dat MIJN implementatie gewoon volgens de standaard is. Goed? Deal?

Ik zie het eerder andersom. Als ik er van uitga dat time_t het aantal seconden sinds 1970 is loop ik risico: Misschien draait mijn programma wel op REWIX, en dan klopt die veronderstelling niet.

Ik moet dus de strftime en difftime functies gebruiken (en die zijn er, want REWIX is POSIX-compliant).

Ik ben het helemaal met je eens dat een andere epoch dan 1970 gebruiken voor time_t een keuze is die je heel goed moet onderbouwen als library-maker. Maar als library-grbruiker moet je time_t nergens anders voor gebruiken dan als input in de ander time.h functies IN HETZELFDE PROGRAMMA!

Overigens is deze discussie al vaker gevoerd: https://stackoverflow.com/questions/471248/what-is-time-t-ultimately-a…

Op 29 september 2023 15:34:17 schreef hardbass:
Ik zou gaan voor een library.

EDIT: heel de discussie hieronder bevestigd dat nog maar eens. :)

??? Heel die discussie gaat juist over de problemen die je krijgt bij het gebruik van de standaard library. Ik ben wel benieuwd welke library je dan zou aanbevelen. :)

De Unix epoch is een willekeurig gekozen starttijd, die oorspronkelijk helemaal niet zo bedoeld was als 'ie gebruikt wordt.
(men verwachtte dat de teller iedere 1e januari om 00:00 uur gereset zou worden en opnieuw ging tellen en dus nooit te groot kon worden)

In de beginjaren is de definitie zelfs 4 keer veranderd...

In 1st edition Unix (November 1971), the manual for the timesystem call stated it returned "the time since 00:00:00, Jan. 1, 1971, measured in sixtieths of a second".
This was a 32-bit value, so even treated as unsigned it could only track about 2.26 years beyond this date.

However the manual page and source code comments describe the system call as "get time of year", the year could not be set,
and the date command and ctime() function (used to format the date and time) did not format a year or even work correctly
with time values larger than 1 year, so it was probably expected that the date would be manually reset each year and the
year 1971 in the manual page was of little significance.

Well, except for the little problem that 1972 has an extra day; regarding that, a note was later added to the bugs section:
"The routine must be reassembled for leap year". Nice.

In 1972 the manual page for the time system call was changed to state that it returned the time since "00:00:00, Jan. 1, 1972",
with the note: "The time is stored in 32 bits. This guarantees a crisis every 2.26 years."

In Fourth Edition Unix (November 1973) the time system call was changed to return "the time since 00:00:00 GMT, Jan. 1, 1970, measured in seconds".
(The manual page is dated August 5, 1973, so that may have been when the changes were originally made.)

This is essentially the current definition, except that the term GMT has been replaced by the more precise Coordinated Universal Time and
clarifications have been made regarding leap seconds.

On systems that return this as a signed 32-bit number, this will work until the year 2038.
Fortunately many systems now use 64 bits for this value.

Wat voegt de discussie over library's toe?

Het gaat over de weergave van het aantal dagen die verstreken zijn. Dat is naar mijn idee niet meer dan een teller! Bijkomend lees ik dat er geen datum ingevoerd hoeft te worden:

En steeds aangeven hoeveel dagen er zijn verstreken sinds nu dus.

We beginnen dus bij 0. en hogen deze waarde iedere dag met 1 op!

Vast gestelde datum verandert niet, en laten we zeggen een jaar.

Ik lees dit als een handmatige reset naar nul. Voeg een functie (lang vasthouden, dubbel drukken, enz.) toe om de waarde handmatig te verhogen en/of te verlagen - altijd handig.

Edit:
Laten we @olan vragen wat er op het display komt! En waar hij vastloopt. Dan kunnen we wat gerichter helpen. :)

[Bericht gewijzigd door OPTOdesign op (12%)]

Op 2 oktober 2023 12:31:41 schreef OPTOdesign:
Wat voegt de discussie over library's toe?

Dit is dus gewoon een teller! Bijkomend is dat er geen datum ingevoerd hoeft te worden:
[...]
We beginnen dus bij 0. en hogen deze waarde iedere dag met 1 op!

Goed plan. Maar
- Dan moet je wel continu actief zijn.
- En je moet weten wanneer een nieuwe dag begint.

Als je al een RTC hebt dan kun je rekenen met de datum/tijd. Maar dat is niet echt simpel, dus dan helpt een library.

Alleen de standaard library voor C/C++ heeft zelf ook weer allerlei haken en ogen. Dat was bij ons op de zaak een reden om een eigen library te maken.