Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt? Bekijk dan ons cookiebeleid.

Meer informatie

Bug in Apple Watch zorgt voor crash na instellen zomertijd

Er lijkt een probleem in de nieuwe generatie Apple Watches te zitten waardoor het horloge crasht als de klok wordt verzet. Australische gebruikers, waar de zomertijd zondag is ingegaan, merkten de problemen als eerste op.

De problemen worden op verscheidene plaatsen online gemeld, waaronder op Reddit. De website 9To5Mac merkt op dat het probleem waarschijnlijk in de Infograph Activity zit die met de laatste generatie Apple Watches is geïntroduceerd; daarmee wordt een tijdlijn van de activiteiten gedurende de dag gemaakt, en het lijkt erop dat met het ingaan van de zomertijd in Australië de software in de war is geraakt. Dat zorgt vervolgens voor een crash, waarna het horloge opnieuw opstart. Gebruikers melden daarbij ook in reboot loops terecht te komen, waardoor de Apple Watch dus in feite onbruikbaar wordt.

Een Reddit-gebruiker merkt op dat het instellen van een watchface zonder de Activity-informatie de problemen kan verhelpen. Dat moet op de iPhone worden ingesteld, waarna de reboot loop tot een einde komt. Het is onduidelijk of Apple de problemen direct gaat repareren; mogelijk werkt de Apple Watch weer normaal wanneer op maandag een 'normale' dag van 24 uur ingaat. Wanneer de wintertijd in de overige delen van de wereld ingaat, zal Apple waarschijnlijk wel een fix klaar moeten hebben om te voorkomen dat de problemen opnieuw optreden. In Nederland en België gaat de wintertijd eind deze maand in.

Apple bracht de vierde generatie van zijn slimme horloge vorige maand uit, en introduceerde daarbij onder andere een groter model vergeleken met de vorige generatie. Daarnaast heeft de nieuwe Apple Watch hardware ingebouwd om een electrocardiogram te maken.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Door Bauke Schievink

Admin Mobile / Nieuwsposter

07-10-2018 • 14:41

273 Linkedin

Reacties (273)

Wijzig sortering
Het is gewoon heel erg complex. Jammer dat het weer gebeurd, maar het is best te begrijpen.
Bekijken anders eens het bekend filmpje van ComputerPhile. Dan krijg je een beeld van waar je allemaal rekening mee moet houden als je zaken rond tijd en tijdzones moet programmeren.
Stel je voor dat elk Europees land een eigen tijdzone gaat kiezen, zoals Juncker nu voorstelt. Dan wordt het nog een beetje ingewikkelder.
Ik stel voor dat we in Nederland dan GMT+40 minuten kiezen.
Klopt, mensen die denken dat werken met tijd simpel is zijn het meest geneigd dit soort fouten te maken. En dat beroemde filmpje van ComputerPhile mist zelfs nog een paar complicaties, vooral rond zomer- en wintertijd.

Overigens heeft Juncker niet voorgesteld dat ieder land zijn eigen tijdzone moet gaan kiezen. Hij heeft voorgesteld dat er een einde komt aan de zomer- en wintertijdwisselingen. De volgende stap is nu aan de lidstaten om te besluiten of ze dat voorstel accepteren (Juncker heeft geen beslissingsmacht, hij kan alleen maar uitvoeren). Aangezien er de mogelijkheid bestaat dat sommige lidstaten een betere tijdzone willen kiezen dan ze nu in zitten heeft de Europese Commissie dus ook gezegd dat landen de mogelijkheid kunnen aangrijpen om hun tijdzone te kunnen veranderen als ze dat willen.

In de praktijk zal die optie tot veranderen van tijdzone waarschijnlijk alleen door Spanje gebruikt worden. Die zijn ooit, tijdens de Tweede Wereldoorlog, gelijkgezet met Duitsland en dat is nooit hersteld. Buurland Portugal zit op West Europese tijd en dat zou voor Spanje ook veel logischer zijn. Daarom wordt het opschuiven van de tijdzone al een tijdje besproken in Spanje. Dan is het logisch om dat samen te laten vallen met het afschaffen van zomertijd. Daar heeft de EC nu de mogelijkheid voor opengelaten.

Dat Nederland uit Central European Time zou stappen of voor iets anders dan een heel uur zou kiezen is flauwekul. Dat staat niet serieus ter sprake.

[Reactie gewijzigd door Maurits van Baerle op 7 oktober 2018 15:45]

Afschaffen van de overgang impliceert niet dat we dan maar continu op wintertijd gaan zitten. De meningen erover zijn verdeeld, maar als we als Benelux voor continu zomertijd (UTC+2) kiezen dan zijn we dus geen CET meer. Dat afdoen als flauwekul is nógal kort door de bocht. Goed, de vraag is natuurlijk wat CET dan gaat zijn.

[Reactie gewijzigd door .oisyn op 7 oktober 2018 16:35]

Hopelijk dat we dus op wintertijd gaan blijven, aangezien dat veel beter is voor ons bioritme, en DAT heeft dus directe invloed op onze gezondheid. Maarja, politici, luisteren doen die niet vaak echt.
Da's helemaal niet waar, er is geen "ideale tijd voor ons bioritme". Het veranderen van tijd, dat is slecht voor het bioritme en is negatief voor de gezondheid. Eenmalig een keuze maken tussen zomer- en wintertijd, dat is de discussie.

Ik ben het erover eens dat het WISSELEN van tijd niet goed is. Maar persé wintertijd behouden? Daar ben ik het helemaal niet mee eens, en elk argument die pro-wintertijd komt aanzie ik als quatsch.

Zomertijd is veel fijner doordat het in de zomermaanden de verdeling tussen vroeg licht-laat donker beter verdeeld is dan wanneer we wintertijd zouden behouden. En dan het argument "Maar dan is het in de winter pas zo laat licht en is de ochtendspits in het donker :'( "

Bekijk volgende tabel met tijden rond zonsopgang- en ondergang: http://www.astro.oma.be/GENERAL/INFO/nzon/zon_2018.html#12

Bij wintertijd is het schemering om 8u03 en zon volledig op om 8u45. Om 8u45 is de ochtendspits voor schoolgaande kinderen al lang voorbij, dus de kinderen hebben al in het donker naar school gefietst. Voor het zakelijke verkeer is ook al een groot stuk van de ochtendspits in het donker doorgegaan, dus als de schemering een uur later valt (9u03), daar gaat niemand over vallen, toch? Het zou 's avonds, wanneer schoolkinderen naar huis komen en wanneer de spits weer op gang komt, en wanneer iedereen meer vermoeid is na een lange werkdag, licht kunnen blijven tot 17u39, schemering eindigt dan om 18u18!

Het is nu al een feit dat de wintertijd slechts 5 maanden duurt en de zomertijd de overige 7 maanden van het jaar. Puur wintertijd gaat gevoelsmatig bij veel mensen niet goed aankomen. (En wat heb je zelfs aan dat het in hoogzomer al om 4u29 licht begint te worden 8)7 Dat gaat pas een mooi effect hebben op ons bioritme... )
Zie de plaatjes in deze tweet: https://twitter.com/Marco...tatus/1035933679531507718, dan zie je meteen wat de meest ideale tijd is om aan te houden (en deze: https://twitter.com/Marco...tatus/1036187770933456896)
Als er nog een diagram zou staan dat rekening houdt met schemering, zou het helemaal mooi zijn om te vergelijken O-) Schemering zorgt immers ook al voor licht, en wintertijd in de zomer zou zorgen dat het al vanaf 3u45 licht zou worden...

Ik zie persoonlijk ook meer voordeel in een verlichte avondspits. Ik ben ervan overtuigd dat het beter is om vermoeide mensen in een lichte omgeving te laten rijden dan in pikkedonker.

Meer vervroegen (en dus teruggaan naar GMT) lijkt me al helemaal geen plan. Dat gedoe +20min ook niet.

In een van de comments van Dr Marco zegt ie "Eigenlijk is zomertijd hardstikke idioot voor een niet Midden-Europees land als Nederland.", en dan vraag ik me af: waarom?

Zijn argumenten:
  • "En niet alleen is zomertijd idioot voor onze lengtegraad: als we het over het hele jaar invoeren is het zelfs gevaarlijk!" en "Mensen hebben enige tijd daglicht nodig om alert & wakker te worden. Vóór zonsopkomst opstaan heeft een risico dat je daarna cognitief sub-optimaal functioneert, zo tonen studies aan." -> Mensen vertrekken om 6u met de auto, dan is het donker en worden we dus wakker zonder daglicht. Misschien dat hij vanuit zijn bed direct aan zijn werk begint, maar ik mag nog een uur karren voor ik op m'n werk aankom. Ik douche me en maak me klaar, dus tel snel 2u voor mijn werk begint, dat ik opsta. Hoe dan ook, het blijft donker als ik vertrek of aankom op mijn werk. Niet iedereen begint om 9u...
  • "wintertijd of GMT past veel beter bij het ritme van ons land." en "Kijk naar de diagrammen, naar de traditionele werkdag, en naar ons circadisch ritme." en "Er is één optie waarin over vrijwel het hele jaar de 9-tot-5 werkdag geheel in daglicht is: dat is WINTERTIJD.
    Bij zomertijd beginnen in de winter werkdagen al ruim vóór zonsopkomst." -> Waarom zou mijn hele werkdag in zonlicht moeten zijn? Ik werk tot 17u en dan is het ook donker in de winter. Waarom zou het dan een issue zijn als het tot 9u30 donker is, maar 's avonds tot 18u licht?
  • "Bij continue zomertijd, beginnen in de winter mensen slaperig aan hun werk én aan de reis naar hun werkplek. Dat levert (a) slechter werk op en (b) een verhoogd risico op ongelukken." "Dat verhoogde risico op ongelukken komt nog een tweede keer terug, in de avond. Zonsondergang in de winter is dan nét iets na het einde van de werkdag, als mensen naar huis rijden. Voor (vermoeide) automobilisten zijn zulke laagstaande zon situaties gevaarlijk (verblinding)." Maar dat probleem is er tijdens het voorjaar/najaar ook, en volgens mij is het gevaarlijker in het donker rijden dan bij klaarte/schemering.
  • "Zijn er dan geen nadelen aan continue wintertijd of GMT? Natuurlijk wel. In de zomer is het bij CET of GMT al allejezus vroeg licht. Maar dat is het sowieso in de zomer, ook omdat op onze breedtegraden in de zomer de schemering heel lang duurt." En dat wuift ie weg alsof er niets aan het handje is
  • "Nogal wat mensen reageren met: "maar ik begin niet om 9:00 maar eerder!". Wel, des te meer reden om voor wintertijd te kiezen! Realiseer je, bij continue zomertijd komt de zon in de winter pas om 10:00 op." -> Neen jongeheer, schemering vanaf 9u.
Ik kan niet anders dan beoordelen dat het een bevooroordeelde irritante kwal is die persé via (onjuiste?) "wetenschappelijke" argumenten zijn mening wil bewijzen met argumenten die weerlegbaar zijn.

[Reactie gewijzigd door KingFox op 8 oktober 2018 14:30]

Dat is meestal op Twitter zo hoor. Sommigen maken daar een sport van :D
Voor mij persoonlijk past wintertijd icm 9-5 kantoortijden veel beter bij mijn bioritme. Niet iedereen kan naar wil inslapen en wakker worden. GMT+0 zou nog beter passen en GMT-1 zou helemaal ideaal zijn

[Reactie gewijzigd door AmazingDreams op 8 oktober 2018 16:37]

Zomertijd is kunstmatig .. wintertijd is de normale tijd. Laat ze die maar gewoon aanhouden.
Zelfs wintertijd is voor ons foutief. Wij zouden namelijk op GMT+0 moeten zitten. Het is omdat de bezetters ons in de twee wereldoorlogen naar GMT+1 hebben geduwd dat we na WOII dan maar besloten hadden om op GMT+1 te blijven ipv nog maar eens naar GMT+0 te gaan.
"we zouden?" Op basis waarvan? Arbitraire regels die al lang niet meer bij de maatschappij van vandaag de dag passen. Waarom moet de zon per se om 12:00 op z'n hoogste punt staan? We gooien we hoop licht weg terwijl we nog in bed liggen, 12:00 is doorgaans niet het midden van de dag. Als je om 7 uur opstaat en 23:00 naar bed gaat dan is het midden om 15:00.
In Nederland staat de zon altijd gemiddeld 12:39 (west Nederland 12:46, oost Nederland 12:32) op het hoogste punt ("midden van de dag"). In de winter en in de zomer. Alleen hebben we door de zomertijd de situatie dat er dan 13:39 op de klok staat.

Doordat de zonsopgang 's ochtends ongeveer evenveel tijd afneemt en toeneemt als het omgekeerd evenredige voor de zonsondergang 's avonds, bijft het hoogste punt dus altijd (ongeveer) gelijk. Dit is wezenlijk waar de eerste klokken op gebaseerd waren.

Voetnoot:
Vroeger had je 'per stad' een andere tijd. Ieder gemeentehuis en/of kerk had een grote klok die de "officiële tijd" weergaf. Toen de treinen populairder werden, werd dit onpraktisch en hielden de nationale spoorwegmaatschappijen van landen één tijd (in de eerste instantie per land :), maar dit werd al snel gesynchroniseerd) aan. (anders was het onmogelijk om een precies spoorboekje te kunnen maken). De individuele steden en daarmee dus effectief het hele land zijn toen die tijden aan gaan houden. Omdat anders de stationsklok en de gemeenteklok een afwijking zouden hebben (die soms best groot was). Uiteindelijk is het hele gebeuren in wetgeving opgenomen.
Dat komt door UTC+1. We zitten dichter bij UTC+0, waarbij hij gemiddeld om 11:39 op zenith zou staan. Het midden van de tijdzones zijn zo gekozen dat 12:00 zenith is (vandaar dat ik het over 12:00 had), maar ja, niet iedereen kan natuurlijk exact in het midden van een tijdzone wonen. Maar ik vind het niet een keuze die nog bij onze samenleving past, daarom zie ik liever de shift naar UTC+2.
Nu snap ik je :)
Het feit dat het 'natuurlijk/cosmisch' zo is, betekend niet dat dit optimaal in onze maatschappij past (gezien de meeste mensen tussen 08:00 en 18:00 werken/op school zijn. Daar heb je denk ik wel een goed punt. We hebben natuurlijk ook wel onze biologische klok, maar ik denk dat dat niet heel veel zal uitmaken linksom of rechtsom.

Maar zou het dan niet practischer zijn om te zeggen dat we allemaal een uur vroeger gaan werken. Dus niet '9-17' maar '8-16'? Dan hebben we nog steeds 'het midden van de klok' als hoogste/warmste/middelste punt van de dag en we hebben nog steeds meer profijt dat we nog iets meer zonlicht zien?
Klopt, het maakt natuurlijk strict gezien niet uit wat we doen - klok verzetten of tijden verzetten. Maar ik denk dat het eerste een stuk simpeler is dan het tweede, en de "correctheid" van de tijdzones kan me persoonlijk gestolen worden ;)
Het "midden van de dag" lijkt mij het moment dat de afstand tot de schaduwgrens op de aardbol via oost en west even lang is...
Exact :). Jij hebt het over het natuurlijke midden, ik om het midden van de dag onze dag in het dagelijkse leven, waarbij de dag de periode tussen opstaan en naar bed gaan ligt. Het lijkt me praktisch die twee middens aan elkaar te ijken. Dus 15:00 de zon op het hoogste punt.
Op werkdagen vind ik 8 uur ‘s ochtends nog midden in de nacht.... 😜
Voor de bezetting liep de tijd in Groningen anders dan in Amsterdam. Dat kon 10 minuten schelen.


De Duitsers hebben de boel toen centraal gebracht naar 1 tijdzone en dat beviel wel.
Nee, Amsterdamse tijd (UTC+0:20) is in 1909 nationaal ingevoerd (dus ook in Groningen) en door de Duitse bezetter in 1940 juist afgeschaft voor onze huidige Midden-Europese tijd.
Dat zou op zich nog logischer zijn inderdaad..
Er is (inhakend op de discussie hierboven over arbitrair etc) ook wat voor te zeggen om helemaal niet meer in tijdzones te denken. Je bent dan van veel verwarring en omrekenen af: 13 uur op 10 oktober is overal op hetzelfde moment.
"Captain's log, stardate: 07102018.1959" :)

Ja dat zou op zich ook kunnen. Een universele tijd. Maar om nou termen als 's avonds en 's middags te gaan schrappen, wereldwijd, lijkt me een gedoetje.
Een notatie waarbij bijvoorbeeld bestanden in chronologische volgorde komen te staan is wat praktischer, dus 20181007.1959 in dat geval.

's Middags en 's avonds zijn nou juist mooie voorbeelden van termen die altijd overeind blijven. Ook als we een andere notatie gebruiken.

De indelingen van klokken en kalenders zijn zeer arbitrair. Waarom 60 seconden, 60 minuten, 24 uur… 12 maanden etc volhouden terwijl de redenen daarvoor al lang niet meer van toepassing zijn en we voor ongeveer alles een decimaal systeem gebruiken?
Omdat het gebaseerd is op de rotatie van de Aarde. 365 dagen en 6 uur, pakweg, rond de zon en ruwweg 24 uur om z’n eigen as.
Kun je nog steeds 10 maanden per jaar doen, 10 uur per dag, 100 minuten per uur en 100 seconden per minuut. Bijvoorbeeld.

Getallen als 12, 24 en 60 zijn vooral gekozen omdat ze zoveel delers hebben.

[Reactie gewijzigd door .oisyn op 8 oktober 2018 08:55]

:) grappig

Die 365 rondjes om de as van de aarde tijdens een rondje om de zon liggen vast, ja, maar die indeling in zoveel maanden, weken, 24 uur in een dag, 60 minuten in een uur en 60 seconden in een minuut zijn nogal willekeurig gekozen.

Waarom bijvoorbeeld niet 100 seconden in een minuut, 100 minuten in een uur, 10 uur in een dag gekozen?
Dat volhouden aan verschillende systemen heeft en aantal redenen, de belangrijkste is vaak dat de kosten van het gelijkschakelen enorm zijn. Dit terwijl het inderdaad op de lange termijn gunstiger kan zijn om het wel te doen, maar het is nogal een investering die op een zeker moment gedaan moet worden. Andere voorbeelden waarvan iedereen weet dat het beter universeel geregeld kan worden maar wat niet gebeurt
omdat het bijvoorbeeld te veel kost: Toetsenbord-indeling, links/rechts rijden, verschillende breedtes op het spoor, metriek stelsel versus wat er al niet gebruikt wordt in bijvoorbeeld de USA. Maar er zijn vast nog veel leukere voorbeelden :)
Je zou bijvoorbeeld het decimale tijdstelsel kunnen hanteren. Tien uur in een dag, 100 minuten in een uur. Tijdens de Franse Revolutie was dit bedacht en, of ingevoegd, of ze waren het van plan (weet niet meer zeker of het nou daadwerkelijk hadden doorgevoerd).

Swatch had eind jaren 90 (de periode dat chatboxen nog erg populair waren) dat concept opgepakt en noemde het (dom genoeg?) Swatch Internet Time. Het idee was dat je dan met z'n allen kon zeggen. We spreken af om 315.2 (wat in Nederland dan ongeveer 10:50 en in Australië bijvoorbeeld ongeveer 17:50 (getallen/tijden kloppen vast niet, maar je snap het concept :) )

De 0 was 00:00:00 GMT (hoewel door de naam "Internet time" het meer doet suggereren dat ze UTC aan zouden houden ipv GMT, maar dat is waarschijnlijk te simpel gedacht van mij :) )
Dat van die Swatch weet ik nog! Dat was toen tijdelijk wel een dingetje ja.. maar niet doorgebroken, helaas.
Deze discussie had ik al eens met iemand die niet begreep waarom server maintenace, release schedules, en dergelijke niet op dezelfde tijd waren voor iedereen. Als ik aan jou vanuit de VS zeg dat ik iets om 13u op 10 oktober nodig heb, wiens tijd is de waarheid als we de 9-5 werkdag aanhouden? Als het jouw tijd is dan ben je vast al aan tafel voor het avond eten. En omgekeerd zou ik dan onderweg zijn naar kantoor. Iedereen dezelfde tijd werkt niet als we nog een dag en nacht ritme hanteren voor het leven.

De andere begreep niet hoe een release tijd van 00:00 GMT+0 ongeacht waar op de wereld toch voor iedereen tegelijkertijd beschikbaar was ook al was de ene kant vrijdag middag en de andere kant de vroege ochtend van zaterdag. Als iedereen ongeacht tijdzones een release hadden als de zon op komt, dan zullen mensen het veeeel vroeger krijgen dan anderen.

Tijdzones werken. Maar landen moeten niet mieren neuken door 5:30 zonder zomertijd te gebruiken als de buren 5:00 met zomertijd hanteren.
Deze discussie had ik al eens met iemand die niet begreep waarom server maintenace, release schedules, en dergelijke niet op dezelfde tijd waren voor iedereen. Als ik aan jou vanuit de VS zeg dat ik iets om 13u op 10 oktober nodig heb, wiens tijd is de waarheid als we de 9-5 werkdag aanhouden? Als het jouw tijd is dan ben je vast al aan tafel voor het avond eten. En omgekeerd zou ik dan onderweg zijn naar kantoor. Iedereen dezelfde tijd werkt niet als we nog een dag en nacht ritme hanteren voor het leven.
Dat een werkdag om 9 uur begint is ook maar een afspraak. Wat een uur is en hoe laat die precies beginnen is niet altijd geweest zoals we het nu doen. We zijn nu dit gewend maar als één, 'universele wereldtijd' de laatste 100 jaar de standaard was geweest, had iedereen het net zo normaal gevonden. Dat dag en nachtritme houden mensen inderdaad toch wel aan. We gaan ook niet om middernacht naar ons werk omdat dan toevallig de nieuwe dag begint volgens de kalender of de klok.
Tijdzones werken. Maar landen moeten niet mieren neuken door 5:30 zonder zomertijd te gebruiken als de buren 5:00 met zomertijd hanteren.
Tijdzones zijn een conventie, (bovenop de conventie van 60 seconden / 60 minuten / 24 uur / GMT van het SI etc), waardoor bijvoorbeeld 13 uur bij iedereen aan het begin van de middag valt.

Wat betreft het voorbeeld dat er onduidelijkheid kan ontstaan wanneer 'de werkdag' nou precies valt is: Dat is een type probleem, wat je nu net zo goed hebt. 'Morgen' is op dit moment (23 uur, zondagavond 7 oktober) voor mij over uur. Dan wordt het voor mij maandag, terwijl het voor mijn collega in Singapore al vijf uur maandagochtend is.

Tijdzones werken.. Tja, omdat we er mee opgegroeid zijn en niet beter weten, maar het is vandaag de dag niet de betrekkelijk elegante oplossing meer die het ooit was. Het is bijvoorbeeld raar dat het in elke tijdzone op een ander moment nieuwjaar is. Alsof tijd een soort traag verschijnsel is dat er 24 uur over doet om de aarde rond te komen. Dat is onzin, maar zo wordt het nu wel neergezet. Als er een jaar om is, als de aarde een rondje om de zon gedraaid heeft bijvoorbeeld, of als er een syteem-update beschikbaar gemaakt wordt, dan is dat overal op hetzelfde moment zo. Het voorbeeld van de persoon die niet begrijpt dat een update op hetzelfde moment beschikbaar komt.. dat soort verwarring ontstaat juist doordat de tijdzones-afspraak de illusie in stand houdt dat middernacht en 0:00 uur samengaan.

Het idee van tijdzones werkte goed in de tijd dat je eigenlijk nooit te maken had met mensen die echt ver weg waren. Nu je net zo makkelijk kunt bellen, video-chatten, handelen, tv-kijken etc naar gebieden overal op aarde, moet je steeds tijden 'omrekenen'. Dat is niet handig. Ik denk dat het tijdzone-principe minstens zoveel nadelen heeft als werken met een globale of beter gezegd universele tijd / klok.
Interessant weetje over de Nederlandse tijd:

RFC 3339: 1937-01-01T12:00:27.87+00:20
This represents the same instant of time as noon, January 1, 1937, Netherlands time. Standard time in the Netherlands was exactly 19 minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through 1937-06-30. This time zone cannot be represented exactly using the HH:MM format, and this timestamp uses the closest representable UTC offset.

[Reactie gewijzigd door Malarky op 7 oktober 2018 21:37]

Volgens mij hebben op GMT+0:20 gezeten. Amsterdamse tijd. Probeer dan maar eens een goed internationaal overleg te plannen. De bezetter kon daar niet mee overweg. Ik denk dat +0:20 voor niemand leuk is nu...
Élke tijd is kunstmatig. Als je de reguliere tijden van de samenleving gelijk houdt, dan is het maar net hoe je het zonlicht over de dag wilt verspreiden. Doe mij maar lekker continu zomertijd dan. Heb je in de winter aan het eind van de middag nog een beetje licht, en gaat het 's zomers niet al om 4:00 's nachts schemeren.

[Reactie gewijzigd door .oisyn op 7 oktober 2018 17:47]

Laat ik het minder esoterisch zeggen: we hadden altijd de wintertijd, en vanwege de oliecrisis moest daar ineens zomertijd bij komen. Dus kun je die het eerste afschaffen. Wil je meer zonuren? Verhuis maar richting de evenaar.
Jij vindt dus dat we datgene moeten doen wat we vroeger altijd deden, in plaats van nu nog eens te evalueren wat het handigst is en waar men op zit te wachten. Waarom dan precies? Wat we toen deden was ook maar arbitrair.
Als het dan toch moet 1 tijd aannemen dan lijkt zomertijd mij het meest praktische.
Maar van mij mag het blijven zoals het nu is, winter én zomertijd.

Wat betreft het vermijden van die crash: test procedures.
En nee je kan niet alles testen maar wel zeer veel. Instellen van zomer/wintertijd is zéér makkelijk te testen, een crash als dit valt dan ook makkelijk te vermijden.
Shame on Apple voor dit....
Ik zou het gelinkte filmpje eens kijken als je denkt dat het makkelijk is. Om alvast één voorbeeld te geven zelfs binnen de VS wordt de klok niet in hetzelfde weekend verzet.
Hoe lang wordt er al geprogrammeerd met tijd? 't Is niet alsof er nu een bufferoverrun plaatsvindt of zo die een crash veroorzaakt.
Het is niet goed geschreven, en de testcases hebben het niet afgedekt. Want dat is mijn indruk bij Apple: de kwaliteit komt niet voort uit ontwer, maar uit testen. Reden waarom de boel instort als je je op onbegaande (error) paden begeeft.
  • Zet de klok van je toestel op handmatig en een paar jaar vooruit: server-certificaat bij Apple is expired en je kan je software-update niet activeren.
  • Stuur een te grote mail: het mailprogramma wil daarna helemaal geen mail meer sturen.
  • Een 802.x certificaaterror wordt niet getoond, maar verschijnt pas als je een Apple built in app start.
  • Als een wifi-verbinding maken niet lukt verschijnt soms de onterechte melding dat de passphrase wel verkeerd zal zijn
Voor de rest loopt alles soepeltjes hoor.

[Reactie gewijzigd door sympa op 7 oktober 2018 21:07]

Nouja, niet arbitrair want toen volgden we gewoon de natuur, als in 'met de kippen op stok'. Tegenwoordig werken we, althans de meeste mensen, niet meer met kippen dus dan is de 'zomertijd' een stuk handiger, ook in de winter.
Maar je verwart de standaard tijdsstip die we hanteren met de tijd die we eraan koppelen. We kunnen prima leven zoals we nu leven maar de klok op UTC-5 zetten bijvoorbeeld - we hoeven alleen de standaard tijden aan te passen (school begint dan om 2:30 ipv 8:30).

Het tijdsstip dat we opstaan is redelijk gebaseerd op de natuur en daardoor idd niet zo arbitrair. Dat we die tijd 7:00 noemen is dat echter wel.
Nee, want het is nog steeds volledig arbitrair welke getalletje je hangt aan de tijd van de kippen. Er is niets intrinsieks aan om die tijd 5, 6, 7, of 20 uur te noemen. En dan heb ik het nog niet eens over dat als je 'de kippetjes volgt' je elke dag met andere klok moet werken, omdat die kippetjes elke dag op een ander tijdstip wakker worden.
Omdat de Aarde nou eenmaal nog steeds dezelfde kant op draait als altijd, jaargetijden en zons op- en ondergang ook vrij constant is, en wintertijd daarop gebaseerd is. Ik verzin het óók niet...
Je draagt geen enkel ander argument aan dan "vroegâh". Sorry, maar daar ga je me niet mee overtuigen. Waarom vind jij UTC+1 zo belangrijk?

[Reactie gewijzigd door .oisyn op 7 oktober 2018 17:50]

Je draagt geen enkel ander argument aan dan "vroegâh". Sorry, maar daar ga je me niet mee overtuigen. Waarom vind jij UTC+1 zo belangrijk?
Dat niet, maar als er geen enkele reden is het te veranderen, is het praktischer om het te laten zoals het was, zodat je dan niet hoeft om te rekenen zodra je iets van 'vroegâh' gebruikt. Zodat je niet het euro / gulden effect krijgt.
Maar er verandert al iets, zomertijd verdwijnt. Voor de rest maakt het niets uit, verschillende tijdzones is iets waar je vandaag de dag al rekening mee hoeft te houden.
Er op gebaseerd wanneer en welke argumenten exact? We zijn geëvolueerd (kunstmatig licht, andere werkuren, meer verkeer, etc.) , en eventueel is door die evolutie de andere tijd beter, laat het ons bekijken en de beste keuze nemen, onafhankelijk van wat er vroeger was. En misschien komt de wintertijd dan uit de bus, misschien de zomdertijd

[Reactie gewijzigd door Clemens123 op 7 oktober 2018 17:50]

Evenaar heeft niet meer zonuren, daarvoor moet je naar zuid-afrika.
Hoever ligt dat van de evenaar af? ;)
Wil je meer zonuren? Verhuis maar richting de evenaar.
Je weet niet dat er rond de evenaar juist minder zonuren zijn?
Tijd op zich is kunstmatig. Tijd is gebaseerd op de rotatie van de aarde. Nieuwjaar: kunstmatiger kan het niet. Waarom zou 1 januari het begin van het jaar moeten zijn? De zon doet toch ook nog eens een rotatie binnen de melkweg?! Waarom vieren we die rotatie ook niet?
1 januari is ook alleen maar 'in het westen' het begin van het nieuwe jaar. Het Chinees nieuwjaar is eind februari ergens..

De definitie 'kunstmatig' is imho niet helemaal juist. Precies omdát dit gebaseerd is op de rotatie van de Aarde om zijn as en omlooptijd om de zon. Natuurlijker dan dát ga je het niet krijgen :-)

En de zon draait een rondje in het melkwegstelsel per 200 miljoen jaar ongeveer (bron: "The Galaxy Song" van Monty Python.. wat verrassend accuraat is met dat soort dingen). Dus daar valt voorlopig nog niks te vieren..

[Reactie gewijzigd door DigitalExorcist op 8 oktober 2018 09:16]

Jij stelt dat wintertijd natuurlijker is, terwijl dit feitelijk juist niet natuurlijk is.

Onze wintertijd zorgt er namelijk voor dat men overdag slaapt en ter zelfde datum nog lang na zonsondergang wakker blijft.

Het wordt namelijk dan op zijn vroegst al drie uur eerder licht dan dat men wakker wordt, terwijl men dan nog twee uur na zonsondergang wakker blijft. Uitgaande van een dag van 07:00 tot 23:00.

Voorstander zijn voor een ander dag en nachtritme kan, beweren dat (deels) je nachtrust overdag houden natuurlijker is dan 's nachts slapen kan ik alleen niet serieus nemen.


Dan is er eerst de vraag of we met zijn allen natuurlijker willen gaan leven, in de zin van maximaal gebruik maken van daglicht.
Hier kun je prima nee tegen zeggen en argumenten voor aanvoeren. Zelf ben ik voor.


In de winter is het duidelijk dat het minder lang licht is dan dat wij als mensen wakker zullen zijn. 100% gebruik maken van daglicht is dan ook niet de vraag, hooguit op welk punt van de dag het daglicht zou moeten beginnen. Wat hierin meer natuurlijk is, daarover zijn de meningen verdeeld, in de zomer echter niet. Zonder tussentijdse ongezonde tijdwissel is het gebruiken van de zomer als uitgangspunt dan ook de enig logische keuze voor het maximaal gebruik willen maken van daglicht en dus voor het meest natuurlijk dag en nacht ritme.
Wintertijd was de oorspronkelijke tijd (even gesteld dat we daarvóór nog Amsterdam op +20 minuten of zo hadden tov. Greenwich). Zomertijd is geïntroduceerd ten tijde van de oliecrisis zodat we 's avonds langer licht hadden en 'dus' minder olie hoefden te stoken. Nu dat niet zo'n heel groot issue meer is kan je zomertijd dus schrappen, op zich.

Of we dat *willen* is wat anders. Maar zomertijd is verzonnen, de wintertijd zou je dan kunnen beschouwen als 'normaal'.

Maar we gaan gigantisch off topic hier :P het gaat om een horloge met een bug... en die moet gefixed worden voordat we met klokken aan de slag gaan.
De wintertijd is niet verzonnen bedoel je? Je kunt dus ook beiden schrappen en een derde verzinnen, op zich. Wat normaal is, is subjectief.

7 maanden van het jaar is het nu zomertijd en daarmee meer normaal dan de 5 maanden dat we wintertijd hebben, daarmee is de zomertijd nu meer normaal dan de wintertijd (de uitzondering maakt abnormaal). De situatie van daarvoor heb ik nooit meegemaakt. Dat er ooit iemand geweest is die verzonnen heeft dat het 12:00 is wanneer de zon op zijn hoogste punt staat blijft ook een verzinsel.

Andere mensen hebben verzonnen dat we om 08:30 beginnen met werken, ook een verzinsel. Nog een verzinsel is het meerdere keren per jaar verzetten van de klok is zomer en wintertijd. Dat geeft problemen met meer dan alleen horloges.

Verzinsels waarover afspraken zijn heroverwegen is imho iets goeds. Ouder als beter bestempelen puur omdat het ouder is lijkt me niet zo handig. Alleen omdat iets eerder verzonnen is iets als beter of normaal beschouwen vind ik wat vreemd. Er zijn redelijk goede argumenten om de zomertijd als standaard tijd te gebruiken. Mensen die de wintertijd verdedigen komen niet verder dan 'ja maar vroeger' de 'echte' tijd etc.

Waarom zijn we met zijn allen om 08:30 begonnen met werken en niet om 07:30? Wat is daarvoor de motivatie geweest en is die nog van toepassing? Ik kan me voorstellen dat uit dergelijke vragen nuttige argumenten voor de wintertijd kunnen komen. Ik heb ze alleen nog niet gezien.

Ik heb ook nog van niemand een uitleg gezien waarom het normaal en natuurlijk zou zijn om in de zomer (deels) met daglicht je nachtrust te houden.
Mijn wisselende diensten zeggen dat ik soms om 7.30 begin, soms om 8,30 en soms om 9.00 uur 😜 en mijn biologische klok zegt dat ik rond 23.00 uur wel klaar ben om te pitten en rond 6.45 uur wakker wordt.
*Tijd is kunstmatig. Er is geen "normale tijd".
Onze invulling daarvan is kunstmatig ja. Met tijdzones en zo. Maar tijd meten aan de hand van omlooptijden van de Aarde om de zon, om z'n as, de stand van de zon et cetera is geen kunstmatig construct. "Het midden van de dag" is wanneer de zon het hoogst aan de hemel staat, avond is wanneer die onder gaat en ochtend wanneer die opkomt. Dat de Aarde niet 'rechtop' staat bepaalt dat we seizoenen hebben en het 's winters langer donker is en 's zomers langer licht. Ook dát is niet verzonnen.

De scháálverdeling daartussen zou je kunstmatig kunnen noemen. Maar het is niet overal tegelijk licht, niet overal tegelijk donker, en niet overal hetzelfde jaargetijde. En daar moeten we orde in scheppen.
Oh absoluut, welke tijd we aanhouden bij het afschaffen is inderdaad nog geen beslissing over genomen. Dat de wisseling wordt afgeschaft is overigens ook nog niet besloten, het is voorlopig slechts een voorstel van de EC.

Het is flauwekul om te denken dat Nederland straks ineens in een andere tijdzone dan Duitsland, Frankrijk of Italië zou zitten, dat gaat niet gebeuren. Het is ook flauwekul om te denken dat er iets anders dan een heel uur geschoven gaat worden. Daarom zijn ideeën als +40 minuten ook flauwekul. Buiten Europa veranderen tijdzones niet dus als CET +40 min (o.i.d.) zou opschuiven zou New York ineens 5:40 later zijn en New Delhi ineens 5:10 vroeger. Eén van de redenen achter het afschaffen van de wisseling is om dingen makkelijker te maken, gebroken uren zou precies het tegenovergestelde bereiken.

Het lijkt me overigens dat verder, ongeacht de keuze die de lidstaten nemen, de nieuwe tijd waar landen als Italië en Duitsland straks in liggen per definitie CET zal heten.

[Reactie gewijzigd door Maurits van Baerle op 7 oktober 2018 16:57]

Toch is India bijvoorbeeld UTC+5:30, en zo zijn er nog wel een aantal landen die een gebroken uur hebben.
Maar 30 minuten vind ik dan nog wel meevallen t.o.v 10 minuten. Puur omdat het de helft is van 60 minuten. En het zover ik weet weredwijd steeds per uur of per 30 min verschilt.
Klopt, Nepal op 15 min. bijvoorbeeld.

Maar landen als India en Nepal zijn dus al hoofdpijn genoeg. Om daar nu nog meer hoofdpijn aan toe te voegen terwijl het idee juist versimpelen was...
Inderdaad, er is al zoveel discussie of het ene uur wel beter is dan het andere. Dan is een half uur kiezen helemaal onzinnig.
Nou nee. Als er zoveel discussie is over +0 of +1 dan kom je aan iedereen tegemoet met +0.5.

Dus een halfuur kiezen is wat dat betreft juist een heel goed argument.
Maar als er ook zijn die -1, of +2 willen, dan is het al veel minder duidelijk. Overigens: zegt de uitdrukking 'salomonsoordeel' je iets?
Werken met tijd is klote dat snap ik.

Maar een bedrijf als Apple heeft hier wel duidelijk meer problemen dan andere Os'en. En je zou toch verwachten dat het uitvoerig getest wordt.

Sterker nog. Waarom geen uitvoeringen van software 1 maand "fout" laten lopen. Op die manier heb je nog een maand om het op te lossen.
Een klok die stilstaat geeft ook 2x per dag de juiste tijd aan.
mensen die denken dat werken met tijd simpel is zijn het meest geneigd dit soort fouten te maken.
Kennelijk werken die mensen bij Apple, en kennelijk is het instellen van zomertijd niet getest. Nogal amateuristisch voor zo'n groot bedrijf.
Het meest bizarre is nog dat >tijd< een core eigenschap is voor een >watch<…
Vooral omdat ze bij de release van de Apple Watch (weet niet meer welke versie..) dat de klok zo precies is dat ie hoogstens 20ms afwijkt...
Dat spanjaarden later aan hun werk beginnen (10:00 is vrij normaal) en laat eten heeft ook een beetje daarmee te maken. Vergelijk Spanje met Polen en er is al een flink verschil in wanneer de zon opkomt. In Spanje komt hij laat op, anders gezegd is 09:00 vroeger in Spanje dan in Polen. Overigens in NL zitten we ook best op het randje. Ik was in Dresden (oost Duitsland) en daar merk je het verschil al echt.
Dus eigenlijk is het de fout van de overheid 8)7 Kort door de bocht.

Mensen verdedigen Apple door de oorzaak telkens af te schuiven op iets of iemand anders. Dat zie je zo vaak overal.

Maar als Microsoft een bug heeft in een update, dan is het moord en brand.

Best vermoeiend. Ja het kan ingewikkeld zijn, maar ik denk niet dat dit het eerste proefstuk is en dat ze lang genoeg testen, blijkbaar toch niet alles.

Dus ja, gewoon toegeven, Apple heeft een bug in hun software die ze niet hebben getest en er moeten niet meer woorden aan geschreven worden. Ze maken genoeg fouten in hard en software de laatste tijd, ze zijn net zoals elke bedrijf, ze staan er absoluut niet boven. Het enigste dat erboven staat, is hun prijs, maar kwaliteit, dat kunnen we ondertussen al lang in twijfel beginnen trekken alsook hun support.
Ja, het is complex.

Maar nee, dat is geen excuus. Alle tijdafhankelijkheden zijn prima te testen want het zijn allemaal gewoon regeltjes, er is niets fuzzy aan.

Apple heeft een historie met datum/tijd gerelateerde bugs:
- nieuws: Apple werkt aan patch voor bootloop-bug iOS-apparaten
- nieuws: Apple repareert vastlopers in iOS met 11.2-update
- https://www.iphoned.nl/ni...-wekkers-gaan-te-laat-af/
- https://webwereld.nl/mobi...lapen-zich-door-wekkerbug

Daarnaast bestaan er libraries om de datum en tijd correct af te handelen. Het is niet zo dat elk bedrijf apart het wiel opnieuw hoeft uit te vinden.
Complex of niet. We hebben het hier over een horloge. De primaire functie van zo'n ding is de tijd juist weergeven. Als dat al niet eens (goed) lukt, weliswaar in een bijzondere situatie, wat geeft dit dan voor beeld van het bedrijf?

We hebben het niet eens over een onbekend bedrijf maar over één van de grootste op het gebied van electronica. Dan mag je toch verwachten, zeker voor de prijs waar ze producten voor verkopen, dat dit soort kleine maar zeker complexe dingen in orde zijn. Met de enorme omzet die het bedrijf maakt zal je toch denken dat er ervaren programmeurs zitten die dit soort lastige dingen wel aankunnen. Het is overigens ook niet een heel nieuw fenomeen. De tijd die wisselt tussen zomer en winter bestaat toch al heer wat jaar nu.

[Reactie gewijzigd door Septimamus op 8 oktober 2018 07:48]

Gewoon overal 'Continuous Local Time' ;) (kijk in de Play Store). Zo is het hier nu 14:07, maar op de klok aan de muur 15:48.
Nee, de complexiteit zit erin om de tijd goed te krijgen. Niet om het niet te laten crashen.
GMT + 20 wordt het dan en niet + 40. De zon komt hier eerder op dus wel een plus.

Reken even mee, 360 graden gedeeld door 24 uur is 15 graden per uur (draaisnelheid aarde om haar as).
We zitten hier om 5+ graden Oosterlengte, dus 20 tot 25 minuten extra ten opzichte van Greenwich (de Nul merdiaan).

Het makkelijkste is dan gewoon wel UTC (GMT) in te voeren als lokale tijd hier, dus een permanente zomertijd.
Zonertijd is UTC +2
Ook goed, als het maar ingewikkeld is.
Aangenomen dat men niet zo ver gaat om gebroken uren te gaan gebruiken, zou de tijdzone-scheidslijn dan niet tussen Engeland en het vastland van Europa waaronder Nederland komen te liggen, zoals nu, maar tussen Nederland en Duitsland :X

Maar als je uren gaat breken: waarom ophouden bij landsgrenzen? Elke provincie, elke gemeente zijn eigen tijd! /sarcasme
en vroeger hadden we dat al, toen we eenmaal de trein kregen kon die 'vroeger' vertrekken van een later station, en toen is de tijd in heel NL gelijk gezet. iedere IOS update verwacht ik weer mensen later op kantoor omdat Apple het keer op keer weet te verprutsen... iets met ezels en stenen
Het is gewoon heel erg complex. Jammer dat het weer gebeurd, maar het is best te begrijpen.
Bekijken anders eens het bekend filmpje van ComputerPhile. Dan krijg je een beeld van waar je allemaal rekening mee moet houden als je zaken rond tijd en tijdzones moet programmeren.
https://zachholman.com/talk/utc-is-enough-for-everyone-right
is ook nog een mooie om te lezen.
Zou het wel wat vinden, de hele wereld dezelfde zone. Ja, het is dan even wennen voor de mensen die om 13:00 naar bed moeten en om 20:00 weer op, maar uiteindelijk maakt het, voor zover ik kan zien, een hoop dingen veel eenvoudiger.
Het is gewoon heel erg complex.
Dat is zeker waar. Zo moet je bijvoorbeeld een database bijhouden met voor elk jaar en elke regio de momenten waarop zomertijd en wintertijd ingaan. Dan heb je nog schrikkeljaren en zelfs schrikkelseconden, lokale tijd vs. UTC, tijdzones, die ook in een tabel moeten en ook regelmatig veranderen enz.

Weinig mensen realiseren zich dat als je bijvoorbeeld ziet staan vrijdag 15 oktober 1582 op een document, dat het dan afhangt van waar vandaan dat document komt welke dag dat was. De Gregoriaanse kalender die wij gebruiken (genoemd naar paus Gregorius) is namelijk ingevoerd om een probleem op te lossen in de Juliaanse kalender (genoemd naar Julius Caesar, no less) en om de afwijking die was ontstaan te herstellen hebben ze toen na donderdag 4 oktober 10 dagen weggelaten en zijn meteen verder gegaan met vrijdag 15 oktober. Echter niet alle landen hebben de Gregoriaanse kalender tegelijk ingevoerd. Dat missende gat zit voor die landen dus op een ander moment. In Nederland maakte het zelfs uit uit welk gewest je kwam, want de protestantse gebieden voerden de Gregoriaanse kalender pas veel later in dan de katholieke gebieden.

Echter een crash? Dat vind ik dan weer wel bijzonder. Dat hij een uur ernaast zit kan ik inkomen maar helemaal crashen gaat wel heel ver eigenlijk.
Het kan zo complex zijn als het maar kan. Maar dat is geen excuus voor Apple.

Ze willen universiteit degree ontwikkelaars. Dus tja het is niet 1-2 mensen die ze hebben werken.. dus mag er niet zijn. In andere omgevingen en bedrijven is ander verhaal.

[Reactie gewijzigd door theduke1989 op 7 oktober 2018 23:35]

Sure het is lastig soms om correct met datums om te gaan. Maar je applicatie volledig laten crashen (en in loop belanden) is gewoon slecht programmeerwerk.
Dan krijg je een beeld van waar je allemaal rekening mee moet houden als je zaken rond tijd en tijdzones moet programmeren.
Waardoor je beter een kant-en-klare library van de kast kan plukken (en actueel kan houden) in plaats van zelf het wiel opnieuw proberen uit te vinden.

Overigens is het ergens wel ironisch dat een best wel duur 'slim' horloge moeite heeft met de tijd. :+

[Reactie gewijzigd door The Zep Man op 7 oktober 2018 15:38]

Eigenlijk geld voor werken met tijd hetzelfde als voor werken met encryptie, Don't Roll Your Own. Als je je eigen code gaat schrijven gaat het gegarandeerd fout.
Niet relevant of je een lib gebruikt of niet. Gaat erom dat er geen rekening word gehouden met bv situaties waarin een dag 23 uur is of juist 25 uur. Of wanneer een tijdzone tabel verouderd is.
Ook als je een library gebruikt gaat het nog vaak mis hoor. Dit soort bugs is vaak verkeerd omgaan met een dag die geen 24 uur heeft of met de aanname dat je twee tijdstippen die na elkaar plaatsvinden kan aftrekken van elkaar en dat je dan de periode ertussen hebt. Daar helpen libraries niet tegen.
0Anoniem: 310408
@slowdive7 oktober 2018 16:20
Het is gewoon heel erg complex.
Maar ook erg makkelijk om te testen....
Met het kiezen van een eigen tijdzone in Europa wordt het minder ingewikkeld.
De zomer- en wintertijd verdwijnt dan.

Daarnaast is het niet eens begrijpelijk. De zomer en wintertijd in landen bestaat al meer dan 40 jaar en de data van wisseling van tijd is sinds die tijd allang bekend.

Wat jij aangeeft is recht praten wat krom is.
Hangt van de gemaakte afspraken af. Rutte heeft al gezegd dat Nederland, België en Luxemburg (de Benelux, dus) voor één tijdzone gaan. Als andere landen dat ook zo aanpakken... Goed, iets complexer dan nu wordt het wel, maar minder complex dan zonder afspraken waarbij ieder land een eigen tijdzone kent.
Tijd blijft lastig te programmeren.
Tijd is bijzonder eenvoudig te programmeren zolang je in de achtergrond de tijd maar consequent houdt (op bijvoorbeeld UTC) en alleen de weergave aanpast. Het gaat fout als je iets "doms" als zomer- en wintertijd wat je aan de gebruiker toont in je database/code gaat toepassen voor zaken anders dan het weergeven van de tijd.
Tijd is bijzonder eenvoudig te programmeren zolang je in de achtergrond de tijd maar consequent houdt (op bijvoorbeeld UTC) en alleen de weergave aanpast.
Helaas, zo simpel is het niet.

Stel: je stapt uit de stoel bij de tandarts na je halfjaarlijkse controle en loopt even langs de receptie onderweg naar buiten om vast de afspraak voor over een half jaar in te plannen, 8 Juli om 15:00. Je kalender app slaat netjes de UTC tijd van deze afspraak op, 13:00 UTC, wat door de app correct wordt weergegeven als 15:00 CEST.

Vervolgens schaft Nederland de zomertijd af.

Een half jaar later zit jij een uur te vroeg in de wachtkamer bij de tandarts want je kalender app gaf 13:00 UTC, geheel correct weer als 14:00 CET. Je afspraak was echter niet om 13:00 UTC, maar om 15:00 lokale tijd.
Daarom pleit ik er zelf altijd voor om datum en tijd niet per definitie als UTC op te slaan (ben medeontwikkelaar van Easy Calendar, en wij hebben hier hier destijds hele interessante discussies over gehad :) ). Als je technisch gezien 'tijd logt' dan is UTC logisch. Maar bij een agenda gaat het om afspraken tussen mensen in 'local time' (althans meestal, het is uiteraard anders als je video/call afspraak maakt met iemand in een tijdzone en je vervolgens zelf ook reist en daarmee van tijdzone wisselt). Dus het is beter om zo als zodanig op te slaan. Dus als pure datum + tijd en niet als een of ander abstracte timestamp in de tijd. Omdat juist zo'n timestamp in veel programmeertalen, waaronder Objective-C/Swift, de standaard is (NSDate) gaat het juist vaak mis met agenda's en alarmtijden e.d. Met andere woorden: simpeler is beter!
Het voorkomt ook dat wanneer je een permanente wektijd van 6 uur 's ochtends instelt, dat je wekker midden in de nacht af gaat wanneer je naar een andere tijdzone reist.
Als de programmeur de zomer/wintertijd bij het afschaffen er niet uit haalt loopt je klokje niet meer op tijd. Dat zal meteen opvallen. Waarna je zelf de tijd correct zet en de agenda ook netjes op tijd de melding weergeeft.
De tijdzones, zomer- en wintertijd zitten bij Linux in een aparte package opgeslagen, zodat deze onafhankelijk van je OS / kernel kunnen worden ge-update (tzdata). Daardoor halen de programmeurs de fouten er meestal op tijd uit.

Hoe dit bij Android / iOS / Apple Watch zit, weet ik niet. Maar ik vermoed / hoop dat deze het periodiek van een server trekken, zodat ook oudere devices (die geen Os updates meer krijgen) in de toekomst goed blijven werken.
De tijdzones, zomer- en wintertijd zitten bij Linux in een aparte package opgeslagen,
<snip>
Hoe dit bij Android / iOS / Apple Watch zit, weet ik niet.
Android is toch Linux?
Right, gewoon in UTC werken. En als ik nou een agenda heb met een terugkerende taak elke dag om 12:00, dan moet dat in de winter maar terugspringen naar 11:00?
Right, gewoon in UTC werken. En als ik nou een agenda heb met een terugkerende taak elke dag om 12:00, dan moet dat in de winter maar terugspringen naar 11:00?
Die is nog redelijk makkelijk te ondervangen; reguliere tijd en DST tijd zijn 2 aan elkaar gelieerde tijdzones.
Je kunt de tijd opslaan in UTC; de tijdzone waarin de agenda-afspraak gemaakt is er bij opslaan, en de applicatie kan automatisch tussen regulier en DST schakelen voor weergave.

Het wordt wat meer interessant om af te handelen als je een terugkerende taak hebt en ook geregeld de halve wereld over reist. Moeilijker, maar nog steeds niet onmogelijk: als je weet of een afspraak onder DST gemaakt is of niet, kun je dat gegeven ook toepassen op andere tijdzones - zelfs waar desgewenst DST op andere momenten in gaat.

[Reactie gewijzigd door R4gnax op 7 oktober 2018 17:20]

Zo redelijk makkelijk is het dus niet, want je beschrijving zorgt er juist voor dat je agenda item een uur vroeger plaatsvindt na het omschakelen van wintertijd. Je hebt niets aan een universeel tijdsstip datatype bij een item als "elke dag om 12:00". Dat moet je gewoon ook zo opslaan.

De vraag of dat altijd in jouw lokale tijdzone moet gebeuren is nogal gebruikersafhankelijk. Soms wil je dat wel, soms wil je dat niet. Dit is vooral een UX probleem
Het is vooral niet een UX probleem. De essentie zit 'm juist in hoe je de tijd opslaat. Voor agenda's kun je beter puur datum/tijd opslaan. Zie mijn eerdere reactie.
Als je mijn reacties goed leest moet je toch concluderen dat ik dat probleem wel snap. Wat een UX probleem is, is het feit dat het niet direct duidelijk is wat de gebruiker bedoelt. Als ik elke dag om 14:00 mijn medicijnen moet slikken, dan is het gek als mijn alarm dan 's nachts afgaat als ik in Nieuw Zeeland ben. Heb ik daarentegen elke dag een videoconference om 14:00, dan zit er niets anders op dan die 's nachts te houden in NZ (of te reschedulen).

Dat is weldegelijk een UX probleem. Ik moet bij het inplannen van het terugkerende item op kunnen geven of het een vaste tijdzone aanhoudt, of dat het de tijdzone gebruikt van waar ik dan ook ben.

Ik hou er trouwens niet van om te spreken van UTC; dat is ook maar gewoon een arbitraire tijdzone. Ik spreek van een tijdsstip. De interne representatie die het datatype gebruikt is iets dat me weinig kan schelen, zolang het maar universeel is.
Ik hou er trouwens niet van om te spreken van UTC; dat is ook maar gewoon een arbitraire tijdzone.
Uiteindelijk is alles arbitrair, maar UTC is dé tijdzone die iedereen gebruikt om eenduidig momenten op een tijdlijn aan te geven.

Maar volgens mij moet je heel goed in de gaten houden waar de data voor dient. Als je log regels wegschrijft wil je weten of het ene bericht voor of na het andere kwam; daarvoor is UTC perfect. Werk je echter met een kalender dan is de beleving van de gebruiker veel belangrijker en die heeft bepaalde (soms onredelijke) verwachtingen. Zoals jouw voorbeeld van een alarm wat elke dag om 14:00 af gaat; moet die nu om 14:00 local time (whatever the timezone) af gaan, of elke 24 uur gerekend vanaf 14:00 CET?

In die zin is het zeer zeker een UX probleem. Het moet simpel zijn doch compleet. En dat kan bijna niet want het is juist super ingewikkeld.

Ik had het hierboven over de magische datum tijd 2018/10/29 02:30 CET. Er zijn 2 tijden in UTC die een uur van elkaar af liggen die allebei naar deze zelfde lokale datum tijd converteren. Echter wil je van lokaal naar UTC wat dan? Je kunt een checkbox of zo toe voegen maar welke gebruiker snapt dat? Wat voor een label moet daar naast staan? En die checkbox is feitelijk alleen voor dat ene uur per jaar wat ambigu is... De meeste software negeert dit probleem gewoon en converteert gewoon altijd naar het eerste uur. Met als gevolg dat er feitelijk een uur is dat je nooit kunt kiezen. Probeer eens een afspraak in te plannen op dat moment? Hoe laat je kalender dat zien? Als het goed is zie je gewoon twee momenten van 02:30 en moet je zelf kiezen welke je wilt. Maar de meeste datum tijd velden zijn gewoon een invoerveld en dan kun je het dus gewoon onmogelijk invoeren als er geen checkbox of zo bij staat.
Uiteindelijk is alles arbitrair, maar UTC is dé tijdzone die iedereen gebruikt om eenduidig momenten op een tijdlijn aan te geven.
Over het algemeen wordt er een soort timestamp gebruikt dat het aantal tijdsintervallen vanaf een vast tijdsstip weergeeft. Dat is niet UTC, het is wel te converteren naar UTC, of welke andere tijdzone dan ook. Dat is het datatype dat je gebruikt om tijdsstippen mee te representeren, maar dat is niet "UTC"

[Reactie gewijzigd door .oisyn op 7 oktober 2018 22:11]

Men telt gewoon een aantal milliseconden vanaf de epoch datum.
Die epoch datum is bij Linux timestamps (die de hele wereld gebruikt) 1/1/1970 00:00:00 UTC.
Die UTC is op het eind van de epoch datum maakt dat Unix timestamps inderdaad rekenen in UTC.
Het is het aantal seconden sinds een bepaald tijdsstip. Elk tijdsstip is uit te drukken in een tijd in een bepaalde tijdzone. Het zijn net zo goed het aantal seconden sinds 1/1/1970 1:00:00 CET. Dus volgens jou eigen stelling is het net zo goed rekenen in CET. Puur dat het ijkpunt gespecificeerd is in UTC impliceert niet dat de timestamp zelf UTC is.

Overigens zijn het niet het aantal seconden sinds 1/1/1970 0:00:00 UTC, want schrikkelsecondes tellen niet mee.

[Reactie gewijzigd door .oisyn op 10 oktober 2018 15:21]

Het is het aantal seconden
Dat was het wel ja. Maar inmiddels zijn vrijwel alle systemen overgestapt op ms vanaf dezelfde datum. Try it out for yourself:
var saved = new Date().getTime();
console.info(saved + 'ms since 1/1/1970 00:00:00 UTC');
setTimeout(function(){
var now = new Date().getTime();
console.info(now + 'ms since 1/1/1970 00:00:00 UTC');
console.info((now - saved) + 'ms elapsed');
}, 1000 /* ms */);

// OUTPUT
// 1539178234295ms since 1/1/1970 00:00:00 UTC
// 1539178235298ms since 1/1/1970 00:00:00 UTC
// 1003ms elapsed
Zoals je ziet hoef ik niks speciaals te doen. new Date().getTime() geeft de timestamp in ms. Dit is in Javascript maar werkt hetzelfde in Java, C#, PHP... Volgens mij zijn ze tijdens het Y2K debacle allemaal op 64 bits timestamps overgestapt.
volgens jou eigen stelling is het net zo goed rekenen in CET.
Nee, want CET heeft officieel zomer- en wintertijd.
UTC is als Greenwich Mean Time minus zomer-en wintertijd (DTS, daylight savings time).
UTC is dus speciaal gemaakt om tijdzone onafhankelijk te zijn. Vandaar dat het het makkelijkst rekent in UTC en iedereen dit ook (zoveel mogelijk) doet.
Dat was het wel ja. Maar inmiddels zijn vrijwel alle systemen overgestapt op ms vanaf dezelfde datum. Try it out for yourself:
Zucht, ben je er nou gewoon op uit om op een of andere manier je geljik te halen? Ga liever gewoon inhoudelijk in op mijn punt. Ik las er helemaal overheen dat jij het over millisecondes had, de kern van die eerste zin ging over het feit dat het sinds een tijdstip was, en dat een tijdstip op meerdere manieren is uit te drukken, maar het blijft hetzelfde tijdstip.

Maar als je echt zo pedantisch wil zijn, wat is een "linux timestamp"? Google geeft ook weinig info. Ik dacht dat je een unix timestamp bedoelde, en dat is gewoon het aantal seconden. Niets is daaraan veranderd. Dat verschillende systemen intern een preciezere representatie gebruiken doet niets af aan het feit dat een unix timestamp nog steeds in seconden wordt gespecificeerd. Ik sprak niet voor niets in mijn eerste reactie op jou heel generiek over "het aantal tijdsintervallen vanaf een vast tijdsstip".

Jij gebruikt daar javascript. Die hanteert idd ms. Windows heeft FILETIME, dat is het aantal 100ns intervals vanaf 1-1-1601 0:00:00 UTC. Maar dat boeit allemaal niet echt voor de oorspronkelijke discussie, namelijk dat timestamps tijdstippen zijn en los staan van tijdzones en tijdstandaarden.

[Reactie gewijzigd door .oisyn op 10 oktober 2018 16:05]

Zucht, ben je er nou gewoon op uit om op een of andere manier je geljik te halen?
Niemand dwingt je antwoorden te blijven typen. Overigens zijn we het grotendeels eens volgens mij.
Ga liever gewoon inhoudelijk in op mijn punt.
Note dat ik dit zei naar aanleiding van jouw opmerking:
Het is het aantal seconden
Overigens heb je wel gelijk hoor. 'Unix timestamp' is een nogal losse definitie. Over het algemeen is iedereen het wel eens over de epoch date maar hoe men dit intern bijhoudt verschilt nogal ja. Men wordt er steeds preciezer in. Beter is wellicht om te zeggen 'het aantal 'ticks' sinds de epoch date'.
Maar dat boeit allemaal niet echt voor de oorspronkelijke discussie, namelijk dat timestamps tijdstippen zijn en los staan van tijdzones en tijdstandaarden.
Sorry maar ze staan niet los van UTC. Wel (expres) van timezones.

Overigens ben jij de enige die die discussie voert volgens mij. De algemene discussie ging over de stelling dat simpelweg alles in UTC opslaan je probleem zou oplossen (is gewoon niet zo) en of een dag nou exact 24 uur is of niet...
Ik hou er trouwens niet van om te spreken van UTC; dat is ook maar gewoon een arbitraire tijdzone.
Incorrect. GMT is de tijdzone, UTC is een tijdstandaard.
Greenwich Mean Time (GMT) is often interchanged or confused with Coordinated Universal Time (UTC). But GMT is a time zone and UTC is a time standard.
Bron: https://www.timeanddate.com/time/gmt-utc-time.html
Mijn verkeerde woordkeuze doet verder geen afbreuk aan mijn punt, maar dank je.
Wel in die zin dat UTC niet 'maar gewoon een tijdzone' is. CET is maar gewoon een tijdzone. EST is maar gewoon een tijdzone. UTC is de standaard die iedereen gebruikt als je tijdzone onafhankelijk wil zijn. Theoretisch kun je ook gewoon ms vanaf 1/1/1970 00:00:00 CET tellen en zomertijd negeren, maar niemand doet dat en het zou super onhandig zijn.
De vraag of dat altijd in jouw lokale tijdzone moet gebeuren is nogal gebruikersafhankelijk. Soms wil je dat wel, soms wil je dat niet. Dit is vooral een UX probleem
Bingo. Dat is het hem inderdaad. Het is nogal contextgevoelig of die vertaalslag uberhaupt plaats moet vinden.

Dat is dan ook de crux: de vertaalslag zelf is eigenlijk nog niet zo moeilijk -- mits je correct bijgehouden hebt in welke tijdzone een tijd origineel opgegeven is, kun je de offset tussen twee zones berekenen, deze op je tijd toepassen, en je bent er. Alles heeft een vertaling van/naar UTC; dus dat werkt gewoon.

Het probleem is weten wanneer je deze vertaling toe moet passen, en wat de tijdzones moeten zijn. (Als je niet de juiste zones gebruikt, ben je bij voorbaat al verloren.)

[Reactie gewijzigd door R4gnax op 7 oktober 2018 17:37]

de vertaalslag zelf is eigenlijk nog niet zo moeilijk -- mits je correct bijgehouden hebt in welke tijdzone een tijd origineel opgegeven is
Nee, klopt niet. Helaas.

Het is feitelijk een onmogelijk probleem. Er bestaan in lokale tijd gewoon tijden (momenten) die ambigu zijn. In de nacht van zaterdag 28 oktober 2018 op zondag 29 oktober 2018 wordt de klok een uur terug gezet. Dan begint de klok gewoon opnieuw aan hetzelfde uur! Hoe kun je ooit weten of de gebruiker het eerste uur bedoelt of het tweede als hij voor die datum 02:30 invult??

Dit is het probleem. Net zoals vaak bij conversie is de ene richting simpel en eenduidig, terwijl de andere kant op mis kan gaan.

Integer -> String: simpel, eenduidig, kan niet misgaan: 234 -> "234"
String -> Integer: ambigu, kan mis gaan: "12" -> 12, maar: "hi" -> error
UTC -> local: simpel, eenduidig, kan niet misgaan
local -> UTC, meestal simpel maar voor enkele datum/tijden letterlijk onmogelijk zonder extra informatie

2018/10/29 02:30 CET => ?????? UTC?

[Reactie gewijzigd door OddesE op 7 oktober 2018 21:10]

elke dag om 12:00
Dit is dan ook geen tijd, maar een interval/periode.

Maar ook bij doodnormale tijden heb je al problemen, zelfs als je alles als UTC opslaat. Want de gebruiker denkt niet in UTC maar in lokale tijd. En wil alles ook zo zien. En invoeren. En juist lokale tijd is een puinzooi. Zoals bijvoorbeeld het gat waar de klok van 01:59:59 naar 03:00:00 gaat... En andersom, dat hij van 02:59:59 naar 02:00:00 gaat. Wat als iemand voor die datum als tijd 02:30 invoert? Is dat dan de eerste of de tweede 02:30? Je moet dus feitelijk letterlijk een checkbox of zoiets naast het veld zetten waarin je kunt aangeven dat het dat tweede uur is.
Dit is dan ook geen tijd, maar een interval/periode.
Ik ben dan ook niet degene die beweert "dat je alles gewoon in UTC moet doen" 8)7
Je moet dus feitelijk letterlijk een checkbox of zoiets naast het veld zetten waarin je kunt aangeven dat het dat tweede uur is.
Je kunt ambigue tijden in elk geval herkennen, juist doordat je weet welke tijdzones qua DST en non-DST bij elkaar horen en hoe zich dat relateert tot landen waar deze zones gebruikt worden. (Daar worden databases voor bijgehouden, immers.)

Dus je zou tijdens invoer inderdaad een checkbox kunnen geven of een popup vraag of eender ander geschikt stukje UI wat binnen jouw toepassing past, zodat je weet in welke tijdzone een tijd origineel vastgelegd moet worden.


Maar goed, dat is een hele side-track voor gebruikers die een lokale tijd opgeven binnen agenda applicaties. Doet natuurlijk niets af aan het feit dat een klok ingesteld wordt op UTC en gewoon daarbinnen door hoort te blijven tikken; tewrijl je deze tijd in willekeurig elke tijdzone incl. DST tijdzones weer kunt geven. Je weet misschien niet altijd hoe lokale tijd naar UTC vertaalt vanwege ambiguiteiten met DST, maar UTC naar lokale tijd zou altijd goed moeten gaan.

[Reactie gewijzigd door R4gnax op 8 oktober 2018 20:18]

UTC naar lokale tijd zou altijd goed moeten gaan.
Ja dat gaat inderdaad altijd goed. Het probleem is dat niemand werkt met UTC. Dus je moet altijd eerst de andere kant op vertalen. En de tijdinterval/periode zoals hierboven genoemd kun je waarschijnlijk beter heel anders opslaan. Dus het blijft een complex probleem.
UTC voor data, parsen naar gewenste tijdzone. Dat werkt prima. Er zitten nooit meer dan 24 uur in een dag.

——

Snap wat je bedoelt, klopt. Tenzij je de taak iedere dag er los in zet, dan werkt het weer wel. Ik heb het idee dat wederkerende taken zo ook in kalenderapllicaties zitten. Gelinkt, maar wel als losse items.

[Reactie gewijzigd door BikkelZ op 7 oktober 2018 17:18]

Er zitten nooit meer dan 24 uur in een dag.
Check again.
Nederland heeft elk jaar een dag van 25 uur. En ook elk jaar een dag van 23 uur.

En dat is juist het probleem. Er is letterlijk een heel uur dat niet bestaat in lokale tijd. En er is een uur dubbel! Wat nog veel lastiger is want hoe weet je welke 02:30 het is?? Dus feitelijk kan ik eenvoudig een datum/tijd invoeren (in lokale tijd) die je onmogelijk zonder verdere informatie naar UTC kunt omzetten.
Nee. Die dagen duren ook 24 uur alleen wordt de klok verschoven. Je kunt alle tijden op een dag waarbij van of naar zomertijd geswitcht wordt nog steeds uitdrukken in de tijd van een klok waarbij dat niet gebeurt. Er zit geen gat in de unix epoch.

Schrikkelsecondes zijn lastiger.
Die dagen duren ook 24 uur alleen wordt de klok verschoven.
Nee, echt niet. In lokale tijd is er echt een dag van 25 uur. Sterker nog, die dag komt deze maand weer. Op zondag 29 oktober springt de klok om 02:59:59 opnieuw op 02:00:00...

Dus als je me niet gelooft: Blijf op zondag 29 oktober op tot 00:00 uur en zet je stopwatch. En check de dag erna om 23:59 hoeveel uur er verstreken zijn.

'Een dag' is een UTC ding. In lokale tijd is een dag vloeibaar. Alle 25 uren van zondag 29 oktober krijgen als datum 2018/10/29.

[Reactie gewijzigd door OddesE op 7 oktober 2018 21:39]

Dat is gedrag van de klok, niet van de dag.
Op de dag dat de wintertijd ingaat is het 25 uur lang die dag. Die dag duurt dus 25 uur.

[Reactie gewijzigd door .oisyn op 7 oktober 2018 22:07]

Een dag duurt geen 24 uur: door onregelmatigheden in het wankelen van de aarde zitten er sommige jaren correcties in (schrikkelsecondes). Als je dit niet doet drift de tijd t.o.v. wanneer het licht is (minimaal maar het stapelt op)
Weet niet waarom je offtopic gemod wordt want je hebt helemaal gelijk.

Dé dag bestaat niet. Het enige dat bestaat is dé seconde. Die is door natuurkundigen met gigantische precisie vastgesteld / vastgelegd. En die seconde gaan ze niet meer veranderen want dan moeten ze allerlei constanten e.d. gaan aanpassen en daar hebben ze geen zin in.

De aarde draait steeds iets langzamer om zijn as. Over de jaren heen merken we daar niks van, maar over 100 miljoen jaar duurt een dag op aarde gewoon 25 uur. Dus 'de dag' is niet geschikt als maateenheid voor tijd.

Nu kunnen we met een paar schrikkelseconden per jaar nog de illusie volhouden dat een minuut 60 seconde is, een uur 60 minuten en een dag 24 uur. Maar het klopt nu al niet en die afwijking blijft alleen maar toenemen. Als we over een miljoen jaar nog bestaan zullen we of een extra uur aan de dag hebben toegevoegd, of 2 minuten aan elk uur of iets, want anders verschuift onze kalender tegen die tijd met een uur per dag.
Dat is gedrag van de klok, niet van de dag.
Nee. 'De dag' bestaat simpelweg niet.

Je hebt Universal Coordinated Time. Daarin duurt elke dag precies 24 uur.
En je hebt local time of wallclock time of tijdzone specifc time of hoe je het wil noemen en daarin heb je dus wel degelijk dagen van 25 uur. Dat is ook de reden dat converteren tussen de 2 soms heel lastig is. En dat is waar de hele discussie om begonnen is.

Ik moet zeggen dat deze laatste opmerking van enige koppigheid getuigt (en ik kan het weten :) )

[Reactie gewijzigd door OddesE op 10 oktober 2018 15:14]

Een dag is de tijd dat de Aarde nodig heeft om 360 graden te roteren. Dat gegeven verandert niet. Het enige wat wijzigt zijn de klokken. Zomer- en wintertijd zijn een verschuiving van onderlinge klokken door soms een dag 23 of 25 uur te laten duur op de klok.

Niet de dag verandert, de meetapparatuur verandert.

UTC wijzigt niet, Unix epoch wijzigt niet. Het is daarom raadzaam om tijd nooit in een lokale tijd op te slaan maar dan nog zijn er honderden manier om jezelf in de vingers te snijden.
Niet de dag verandert, de meetapparatuur verandert.
Jawel, de dag verandert:
Because of the way the second is defined, the mean length of a day is now about 86 400.002 seconds, and is increasing by about 1.7 milliseconds per century
Bron: Wikipedia

Het probleem is, 'de dag' is simpelweg niet 24 uur. Niet precies.
Ooit klopte dit per definitie... over de eeuwen heen werd het uur (en dus de minuut en de seconde) gewoon ongemerkt steeds iets langer. Echter sinds de natuurkunde zo precies meet is de seconde tot op ik weet niet hoeveel cijfers achter de komma gemeten en vastgelegd. Met als gevolg dat we nu een langzaam groeiend gat hebben tussen 24 uur en een 'dag'.

De dag is niet houdbaar als meeteenheid voor tijd.

[Reactie gewijzigd door OddesE op 10 oktober 2018 15:48]

UTC voor data, parsen naar gewenste tijdzone. Dat werkt prima. Er zitten nooit meer dan 24 uur in een dag
Behalve dan op de dag dat er een leapsecond word ingevoerd ;)
https://en.wikipedia.org/wiki/Leap_second
Haha ik zeg net het zelfde. Maar dat is dus géén zomertijd probleem én het is universeel. Alhoewel. Iedere tijdzone voert het waarschijnlijk aan het einde van de dag door. Lastig!

[Reactie gewijzigd door BikkelZ op 7 oktober 2018 21:28]

Theoretisch lastig, maar in de praktijk voor de meeste software een non-issue. Niemand plant afspraken op de seconde precies in. Alle software die ik ooit heb gezien negeert dit probleem gewoon volkomen. Zomer- en wintertijd en tijdzones zijn toch wel de grootste problemen en helaas niet te negeren.
Alhoewel. Iedere tijdzone voert het waarschijnlijk aan het einde van de dag door.
Nee, leap seconds worden overal op hetzelfde moment ingevoerd, namelijk om 23:59:60 UTC . Bij ons is dat dus net voor 1 uur 's nachts. Theoretisch kan er ook een seconde worden afgenomen trouwens, dan gaat ie van 23:59:58 naar 0:00:00, maar dat is nog nooit nodig geweest.

.edit: Ik noemde de datums 30-6 en 31-12 voor de momenten van leap seconds, maar lees nu dat het niet per se die datums hoeven te zijn, maar die zijn in het verleden wel altijd zo gekozen.

[Reactie gewijzigd door .oisyn op 8 oktober 2018 11:09]

En de twee dagen per jaar dat zomertijd en wintertijd in elkaar overgaan. Ja, die dagen hebben in lokale tijd dus echt 23 en 25 uur.

Overigens: het erge aan die leap second is dat ze arbitrair zijn (as in wordt centraal beslist op basis van astronomische data, maar kun je niet uitrekenen). Dus hoe duur je Rolex ook is, hij moet elke keer handmatig goed gezet worden als er een leap seconde wordt toegevoegd. Daarom is alles preciezer dan een seconde afwijking per jaar voor een horloge feitelijk nutteloos. Blijft leuk om ermee te pochen natuurlijk, maar je zult hem gewoon net zo goed af en toe opnieuw gelijk moeten zetten.

[Reactie gewijzigd door OddesE op 7 oktober 2018 21:44]

Dan ga je er van uit dat er horloges bestaan die minder dan een seconde per jaar te snel of te langzaam lopen. Ik denk dat dat zelfs bij een dure Rolex niet het geval is.
Die video bevestigt volgende mij precies wat pagani zegt.
Het is dacht ik hiervoor al meerdere keren voorgekomen dat Apple problemen met tijdzones had. Toch maar beter testen, Apple. Grappig dat uitgesproken een watch er moeite mee heeft.
Zo simpel is het anders dus echt niet, en veel, HEEL VEEL developers houden er geen rekening mee.
Toch wel grappig aangezien dit om een klok gaat :+
Ik kan dit soort dingen echt niet rijmen met de jubel- en horrorverhalen over kunstmatige intelligentie ook hier op Tweakers. Volgens allerlei kenners staat AI op het punt de macht over te nemen, waarbij als bewijs wordt opgevoerd dat de computer weer een of ander logisch denkspelletje heeft gewonnen of beter patronen lijkt te kunnen herkennen dan mensen. En afgelopen dagen werden we weer gewaarschuwd door hooggeplaatste militairen over het gevaar van levensgevaarlijk onvermoeibaar doorvechtende die meer te beheersen autonome drones.

Tegelijkertijd lukte het alleen deze week bij twee van de grootste IT bedrijvende met ongetwijfeld de beste programmeurs die je met geld kunt kopen al niet om een paar basisfuncties foutloos te implementeren. Je telefoon laten laden als je er de stekker in steekt. Je systeem updaten zonder dat je data verdwijnt. Je polscomputer een uur vooruit zetten zonder dat het systeem vastloopt. Jongens, dat zijn toch geen onvoorstelbare ingewikkelde situaties?

Als de top van de IT-bedrijven dit soort basale, standaard voorkomende zaken die ze al jaren van tevoren zien aankomen en al honderden keren kunnen testen al niet probleemloos kunnen laten gebeuren wat moet ik dan geloven van hun verhalen over computers die duizenden malen complexere zaken met tal van onbekende grootheden en nooit voorziene situaties wel even foutloos zullen 'oplossen'??

Voorlopig maar duimen dat Apple en Microsoft geen slim, autonoom opladen, updaten of tijdsynchroniseren in hun OS doorvoeren...

Toevoeging: Dit is geen rant, ik vraag het mij echt af wat er nu klopt van al die prachtige verhalen van wat AI ons allemaal gaat brengen. Juist omdat zelfs zo'n heel simpel, al jaren en jaren bekend fenomeen namelijk dat je je telefoon moet opladen en er twee keer per jaar een tijdwissel komt blijkbaar al problemen oplevert bij een bedrijf dat honderden miljarden verdient met die telefoon en er ongetwijfeld een legertje van de beste programmeurs en techneuten aan heeft laten werken.

Ruim twintig jaar geleden was ik bij een demonstratie van automatisch vertalen. Heel indrukwekkend, en volgends de kenners was het eerder een kwestie van maanden dan jaren voordat de programma's en computers zoveel beter waren dat automatisch vertalen net zo goed zo worden gedaan door computers als door mensen.
We zijn nu 20 jaar en een paar Teraflop verder en het automatisch vertalen is nog steeds direct herkenbaar knullig en vaak foutief. Lopen ze straks met AI ook tegen zo'n muur aan? Is het net zoals bij dat vertalen extreem moeilijk om voorbij dat stadium van indrukwekkend en veelbelovend naar 'echt bruikbaar' te gaan? En gezien hoe moeilijk het (blijkbaar) is om zelfs toch niet zo ingewikkelde zaken foutloos aan te pakken lijkt het mij voor het veel en veel complexere AI nog een lange weg.

[Reactie gewijzigd door CharlesND op 7 oktober 2018 16:32]

^ Juist ja, voor de leek lijkt dit heel simpel. De praktijk is echter dat die dingen een stuk gecompliceerder zijn dan je doet voorkomen.

Neemt niet weg dat in dit geval dit getest had moeten worden (het gaat zo vaak mis met zomer/winter tijd, schrikkeljaren en dat soort rare constructies).
^ Juist ja, voor de leek lijkt dit heel simpel. De praktijk is echter dat die dingen een stuk gecompliceerder zijn dan je doet voorkomen.
Nee, het ZIJN simpele dingen. Miljarden electronische apparaten laden gewoon op als je ze aan de stroom legt. Je stekker met allerlei beveiligen en toeters en bellen volhangen totdat het met afstand allerbelangrijkste doel van die stekker, het dagelijks opladen van je telefoon niet meer werkt is jezelf gewoon een brevet van onvermogen geven.

Idem het updaten van Microsoft. Mensen zetten dingen op hun computer die ze doorgaans niet kwijt willen of zelfs onvervangbaar zijn. Het kan best zijn dat het programmeren van een update heel gecompliceerd is maar de allereerste zelfs door de grootste kleuter of leek begrepen hele simpele eis is dat de gebruiker na de update weer over al z'n data kan beschikken. Als een 'update' programmeerteam dat niet voor elkaar krijgt zou ik ze echt een andere baan geven want dan begrijpen ze nog niet zo goed wat ze nu eigenlijk aan doen zijn.
Ten eerste denk ik dat je onderschat hoe simpel de genoemde scenario's zijn, hoe conceptueel eenvoudig ze ook lijken.

Ten tweede is het ontzettend moeilijk sluitende tests te maken. Zelfs al weet je je unit tests heel behoorlijk te krijgen en heb je tal van ketentests, dan nog zijn er na het samenvoegen van de losse softwareonderdelen vermoedelijk nog ongedekte scenario's.

Maar het belangrijkste is vooral dat er de tijd niet is om alles te testen om het op het kwaliteitsniveau te krijgen dat jij graag zou zien. We staan ergens in de Middeleeuwen als het op volwassenheid van softwareontwikkeling aankomt en zou je met de huidige gangbare middelen stabielere software willen maken dat wordt je links en rechts ingehaald door concurrenten die een andere tijd-/kwaliteitafweging maken.

Pas als Apple op deze bug keihard op afgerekend zou worden, verandert er misschien iets. Maar mensen lopen niet zo hard naar de concurrent. Nieuwe features en uitgebreidere hardware is belangrijker dan een crash hier en daar.
Nee, het ZIJN simpele dingen. Miljarden electronische apparaten laden gewoon op als je ze aan de stroom legt. Je stekker met allerlei beveiligen en toeters en bellen volhangen totdat het met afstand allerbelangrijkste doel van die stekker, het dagelijks opladen van je telefoon niet meer werkt is jezelf gewoon een brevet van onvermogen geven.
Ja hoor, voor jou wel en als jij het voor het zeggen had dan hadden we nu gewoon een 230V input aan onze telefoon zitten, want dat is lekker makkelijk. Je gaat voorbij aan het feit dat over USB ook data kan en er dus veiligheidsmaatregelen zijn genomen om er voor te zorgen dat niemand in kan breken op je telefoon via USB. Toch wel zéér praktisch dat dit gewoon tegelijkertijd kan via één kabel, niet waar?
Als een 'update' programmeerteam dat niet voor elkaar krijgt zou ik ze echt een andere baan geven want dan begrijpen ze nog niet zo goed wat ze nu eigenlijk aan doen zijn.
Je hebt duidelijk echt geen kaas gegeten van hoe dit soort dingen in de praktijk werken en wat er bij komt kijken. Ik begrijp je frustratie dat dingen gewoon moeten werken en getest hadden moeten worden maar je reactie vind ik nergens op slaan, sorry.
[...]
Ja hoor, voor jou wel en als jij het voor het zeggen had dan hadden we nu gewoon een 230V input aan onze telefoon zitten, want dat is lekker makkelijk. Je gaat voorbij aan het feit dat over USB ook data kan en er dus veiligheidsmaatregelen zijn genomen om er voor te zorgen dat niemand in kan breken op je telefoon via USB. Toch wel zéér praktisch dat dit gewoon tegelijkertijd kan via één kabel, niet waar?
En toch heeft hij hier wel een (klein) punt. Dat ze de communicatie na een uur blokkeren, is zeker iets voor te zeggen, maar in de USB zitten ook 2 stroom voerende draden die in de basis 5V leveren. Met een iets andere implementatie hadden ze dit ook ze het ook zo kunnen bouwen dat laden altijd mogelijk is. Een oplaadbare batterij laad ook op zonder naar ééntjes en nulletjes te luisteren.
Ik kan dit soort dingen echt niet rijmen met de jubel- en horrorverhalen over kunstmatige intelligentie ook hier op Tweakers. Volgens allerlei kenners staat AI op het punt de macht over te nemen, waarbij als bewijs wordt opgevoerd dat de computer weer een of ander logisch denkspelletje heeft gewonnen of beter patronen lijkt te kunnen herkennen dan mensen.
Allerlei kenners op tweakers zijn dit volgens mij niet van mening, getuige de meest recente meet up (plan: Kijk hier de Meet-up Kunstmatige Intelligentie terug). Het programmeren van tijdzones en zomer- en wintertijd is volgens mij ook straight forward programmeerwerk, heeft weinig met AI of KI te maken. Het zou wel een apart programmapunt waard zijn in het ontwikkeltraject van die tijdlijnsoftware.

Dat het desondanks niet goed gaat verbaast mij wel, omdat oplossingen hoe om te gaan met verschuivingen in de tijd op de plank moeten liggen. En dan gaat het niet alleen over een verkeerde tijd, maar de fout resulteert in een vastloper. De problematiek van tijdverschuivingen is nu niet bepaald van gisteren. Of het als materie moeilijk is voor te stellen maakt hierbij niet uit. Dat dit het geval is weet ik uit eigen ervaring. In mijn werk heb ik te maken met gegevens afkomstig uit wereldwijde transporten en manueel is het altijd goed nadenken wat de lokale tijd op plek x of y is.

[Reactie gewijzigd door teacup op 7 oktober 2018 15:56]

Als AI zelf WatchOS of Windows had geprogrammeerd was het misschien niet gebeurd ;-)
Ik kan dit soort dingen echt niet rijmen met de jubel- en horrorverhalen over kunstmatige intelligentie ook hier op Tweakers.
Zo'n bug heeft geen bal te maken met AI.
Omdat het over apple gaat, en dan klikken we massaal.. Snap dat nou eens :P

Mij al eerder opgevallen:

Al gaat een nieuwbericht over wat dan ook, totaal niet Apple gerelateerd, als het woordje Apple valt door een reaguurder veranderd het artikel op magische wijze in een Apple discussie. Raar maar waar.... (Wetende dat het nu een Apple dingetje is)

[Reactie gewijzigd door Audione0 op 7 oktober 2018 18:55]

Niet alleen bij Apple maar net zo goed bij pakweg Christiano Ronaldo. Valt mij steeds vaker op dat [vul hier een bekende naam in] garant staat voor niet alleen méér reacties, maar ook duidelijke gekleurde standpunten en fanboyisme.

Wel wordt het erger naarnate de faam groter is. Aangezien er weinig namen bekender zijn dan die van Apple is die altijd goed voor veel aandacht, van voor én tegenstanders. Ook als het alleen maar een gerucht is.
Hm, niet de eerste keer dat Apple zit te kloten met de klok.
Hier moest ik ook gelijk aan denken.
Wat ik opmerkelijk vind is dat die bug toen bij apple niet ertoe heeft geleid om op dit gebied voortaan extra zorgvuldig te testen; al is het maar om niet opnieuw voor paal te staan met een bug in iets wat veelal als iets triviaals wordt gezien.
een bug in iets wat veelal als iets triviaals wordt gezien.
Door wie wordt dat als triviaal gezien ? Elke developer met een beetje ervaring kan je zeggen dat werken met tijd verre van triviaal is. Het is een van die dingen die op het eerste gezicht simpel lijken, maar als je er in duikt dan trek je een beerput open. Hetzelfde geldt voor het werken met tekst, lijkt simpel maar is ontzettend complex. Een op het eerste gezicht simpele vraag als 'hoe lang is deze string' heeft al meerdere antwoorden.
Het is ook heel simpel en jaren geleden opgelost d.m.v. Unix Epoch.
De beerput, zoals jij dat noemt, is er dus niet.
Gewoon de timezonedb aanhouden, klaar.
Het is ook heel simpel en jaren geleden opgelost d.m.v. Unix Epoch.
En dit soort simplistisch denken is dus hoe je tijd gerelateerde bugs krijgt.

Een unix-timestamp beschrijft een specifiek punt in de tijd. Helaas is dit meestal niet wat de gebruiker wil. Een voorbeeld: je zet een wekker voor 10:00 's ochtends de volgende dag omdat je om 11:00 een afspraak hebt met een klant in Finland. Je wekker app slaat netjes de Unix timestamp op van het gewenste wek-moment. Die avond reis je af naar Finland, je komt 's avond laat aan, pakt een taxi naar je hotel en ploft uitgeput op bed.

De volgende ochtend gaat je wekker netjes om 10:00 Nederlandse tijd, wat 11:00 Finse tijd is en je hebt je afspraak gemist.
Raar, mijn wekker is tijdzone onafhankelijk (dat heet: floating).
Mijn wekker past zich wel aan aan de tijdzone via sim/gps/rds.
Vroeger draaide je zelf handmatig aan het klokje.

En in mijn agenda app kan ik ook een specifieke tijdzone opgeven bij een event zodat de hele wereld weet dat de afspraak om 10:00u CET is.

Wat wil je nou zeggen? Dat jij je wekker verkeerd bedient of dat een programmeur zat te slapen?

En daar zit de kruks, iedereen gaat uit van zijn eigen zone en denkt niet meer na zoals vroeger.

Agenda/klok: ISO 8601
Rekenen: seconden / epoch

[Reactie gewijzigd door DJMaze op 7 oktober 2018 18:23]

Ik heb een door werknemers zelf in te vullen urenoverzichtje gemaakt in Google Sheets. Begintijd en eindtijd invullen en de formule in de sheet rekent per dag / regel het verschil uit. En telt alle tijd uren, van al die dagen daarna bij elkaar op tot een maandtotaal.

Na enige tijd bleken de maandtotalen soms niet te kloppen, terwijl de dagtotalen toch echt correct werden weergeven en ook de formule voor de maandtotalen was foutloos.

Uiteindelijk bleek dat het mis ging als de eindtijd na middernacht lag. OK, blijkbaar begreep ik als formule-schrijver niet goed goed dit werkte. Mea culpa. Alleen vind ik het op mijn beurt onbegrijpelijk dat de getoonde dagtotalen enerzijds achter de schermen niet klopten (en de maandformule verklootten) en tegelijkertijd tóch het juiste getal lieten zien.

Ongetwijfeld allemaal met libraries in elkaar gezet, al kon ik dat niet controleren natuurlijk.
Bij Google Sheets was het ook onmogelijk om het jaartal te krijgen dat bij het weeknummer hoort. Soms is hoort het eind van december in week 1, soms hoort het begin van januari in week 53. Maar je moest je in behoorljik wat bochten wringen om een datum om te zetten in een "week X van jaar Y" notatie, want dan wil je dus het jaar dat bij het weeknummer hoort, niet het jaar dat bij de datum hoort, maar daar was geen functie voor 8)7. Dan krijg je dus gekunstel als "als weeknr=53 en maand=januari, pak dan jaartal-1"

[Reactie gewijzigd door .oisyn op 9 oktober 2018 13:55]

LOL

Ik hoor het al, ik ben dus niet de enige die wel eens moeite heeft de logica van Sheets te volgen.
Het is inderdaad niet heel simpel. Maar vergeet niet dat hier dus de hele watch crashed als je van tijdzone veranderd. En dat dat blijkbaar niet in tests naar boven is gekomen.
Mensen die denken dat Unix Epoch en een timezonedb dit soort problemen voorkomen zijn de mensen die deze fouten programmeren.

Mensen leven niet in een wereld waar je simpelweg steeds een seconde ergens bij op kan tellen om tijd aan te geven. Er bestaan ook schrikkeljaren en schrikkelsecondes. Er bestaan zomer- en wintertijden die op sommige plekken gelden en op sommige plekken niet, die niet overal op het hetzelfde moment ingaan en die soms veranderen. Zoals Aaargh! al aanhaalt wisselen mensen nog wel eens van tijdzone en er staat in geen enkele timezonedb wanneer ik weer eens van tijdzone wissel, soms meerdere keren per dag.
wisselen mensen nog wel eens van tijdzone en er staat in geen enkele timezonedb wanneer ik weer eens van tijdzone wissel, soms meerdere keren per dag.
Niet alleen dat, maar de meeste afspraken die mensen maken zijn in lokale tijd, niet in een specifiek punt in de tijd (wat een unix timestamp aangeeft). Bij een wijziging in de tijdzone (wat vaker voorkomt dat je denkt) verschuift dan het absolute tijdstip van die afspraak, terwijl de lokale tijd gelijk blijft.

De afschaffing van de zomertijd gaat dat soort problemen veroorzaken, alle tijdstippen die lokaal hadden moeten zijn maar zijn opgeslagen als een unix timestamp zijn dan opeens een uur te vroeg.
Klopt niet helemaal. De unix timestamp is altijd UTC/GMT en die is dus niet een uur te vroeg.
Je gooit daar de juiste timezonedb regel overheen en de tijd klopt weer.
Er is echter wel één probleem (misschien is dat de gene die je bedoelt).

1. je voert een datum in voor zomer 2019 (met zomertijd)
2. deze sla je op in een timestamp
3. de zomertijd wordt afgeschaft
4. de datum is dan inderdaad te vroeg

Maar dit probleem bestaat al jaren. Israël bepaalde vroeger namelijk wel eens om de zomertijd over te slaan.
https://nl.wikipedia.org/wiki/Zomertijd#Isra%C3%ABl

Dit probleem is simpel te tackelen door naast de datumtijd dus ook de tijdzone op te slaan (als dit belangrijk is).
En dat is nou precies wat de mensen achter iCal hebben ingebakken (iCal is van Apple).
Het grappige is dus dat de mensen van Apple zelf zijn vergeten dat ze het probleem allang hadden opgelost.

[Reactie gewijzigd door DJMaze op 8 oktober 2018 09:29]

(.edit: ik moet voortaan even verder lezen, hier stond wat je verderop in je post al zei ;))

Om dan toch nog een duit in het zakje te doen:
Dit probleem is simpel te tackelen door naast de datumtijd dus ook de tijdzone op te slaan (als dit belangrijk is).
Maar dat is dus precies het punt. Jij begon je post met "timestamp + timezonedb" en alsof dat voldoende zou zijn, en daarna realiseerde je dat dat niet voldoende is, door iets langer na te denken over de post van Aaargh!. Dit soort fouten zijn echt zo snel gemaakt. Timestamps zijn gewoon geen goede oplossing voor kalenders.

[Reactie gewijzigd door .oisyn op 8 oktober 2018 11:18]

Artikel gaat toch over "Activity informatie" van de Infograph Activity.
Dat is geen kalender maar een ding over wat je hebt gedaan, naar mijn inzicht.
En iets in het verleden kan prima met een timestamp.
Oh kom op, de discussie was natuurlijk veel algemener dan alleen dit artikel. En de posts waar jij in eerste instant op reageerde hadden het zelfs over een ouder probleem die Apple had met de tijd, namelijk in de wekker.
Ik ben toevallig software engineer, en ik zou dit wel triviaal noemen, aangezien voor dit domein nogal veel libraries bestaan.
Maar ook omdat ieder ander mens kalenders en tijd redelijk goed kan bevatten, durf ik dit triviaal te noemen. En dan komt er ook nog bij dat het hier om een horloge gaat. Daarbij mag je verwachten dat de klok functionaliteit wel foutloos werkt.
Het gaat om een horloge! Dan lijkt me tijd toch wel het meest triviale...
Niet de eerste dat wie-dan-ook zit te kloten met de klok. Tijd en tijdzones, daar moet je van wegblijven als developer, aldus computerphile :)
Het is ook niet de eerste keer dat Apple zit te kloten met een zomertijd/wintertijd verandering.
Dat was best lache, werkte bij/rond designers en bijna 80% was die maandag kwam telaat binnen.
Iedere keer weer bij Apple. En dat terwijl dit heel makkelijk prima te testen valt. Kun je gewoon in geintegreerde tests bij builds doen. En voor een apparaat wiens *primaire* functie tijdweergave is, mag je toch van uitgaan dat zomer/wintertijd-functionaliteit getest wordt?

Vind dit echt een setback voor mijn vertrouwen in Apple.

[Reactie gewijzigd door Keypunchie op 7 oktober 2018 18:51]

Nee joh, dit is een bug on purpose.. nu apple laat zien dat zomer en wintertijd totaal nutteloos is en niet werkt en mensen in beesten verandert zien we volgend jaar september de grootste aankondiging ooit! Zomer en wintertijd verdwijnt en dit komt allemaal door apple! 8)7 :9
Time, you're using it wrong.
Of ze introduceren binnenkort gewoon Apple Time.
Australische gebruikers, waar de wintertijd zondag is ingegaan, merkten de problemen als eerste op.
In Australië is de zomertijd ingegaan. Australië ligt op het zuidelijk halfrond en heeft tegengestelde seizoenen t.o.v. Nederland.

Als Australië ook las heeft van dit probleem, betekent dat dus dat niet dat wintertijd buggy is, maar het wisselen naar zomer- of wintertijd voor problemen zorgt.

Edit: het artikel is inmiddels aangepast

[Reactie gewijzigd door P1nGu1n op 7 oktober 2018 15:31]

En dan te bedenken dat de Nederlandse overheid misschien wel Zomer/Winter tijd wilde afschaffen ;)

Maar Apple komt de laatste tijd wel vaak in het nieuws met Bugs etc.. Wel erg jammer :(

Het begint er langzaam op te lijken dat Android tegenwoordig de veiligere keuze wordt.
Dit ze je wel vaker bij Apple. Fouten/bugs die het hele device laten crashen.
Ik bedoel doen ze niet aan foutafhandeling in hun software?
Een try/catch is gewoon een lompe operatie. De software die je tijd afhandelt wordt normaal gesproken dusdanig getest dat je geen fouten verwacht dus wordt de afweging gemaakt het achterwege te laten.
De opmerking "Er lijkt een probleem in de nieuwe generatie Apple Watches te zitten" lijkt mij incorrect, het probleem zit in het OS.

Als het in de watch zelf zit is een een HW issue wat lastiger is op de lossen met een update.
Da's een ontzettend knullige bug, zeker in een horloge... maar waarom crasht meteen het hele apparaat? Ik dacht dat we software tegenwoordig op zo'n manier ontwierpen dat de crash van een programma niet meteen het hele OS mee onderuit trekt...? Met andere woorden: dat "Activity-informatie" crasht is jammer, maar hoe is het mogelijk dat de rest van het apparaat ook niet meer werkt?
Iedereen lijkt hier te doen alsof tijd heel complex is. Dat is tot op zekere hoogte waar maar er is een basis kennis die het behoorlijk versimpeld. Er is een "echte" tijd, die met 60 minuten in een uur, 24 uur in een dag en 7 dagen in een week. En er is een "weergave" tijd met mogelijk 23 of 25 uren op een dag. Je rekent altijd met de echte tijd en laat dan aan de gebruiker de tijd zien die voor hem relevant is.
Dit is dus echt wel een amateuristische bug, zeker als je al voor een horloge aan het ontwikkelen bent. Het idee dat er een zeer goed ontwikkelteam bij Apple werkt is voor mij toch echt aan het wankelen. Hun tooling voor het maken van apps voor bijvoorbeeld krijgen ze ook maar niet op orde.
Het gaat hier over activity tracking. Dat doet Apple op OS niveau en een app heeft dan toegang tot de data. Ze doen hetzelfde met je locatie, apps zien ook niet of je achterliggend de GPS aan hebt of niet. Op zich maakt dit het programmeren net eenvoudiger, je krijgt gewoon data waar je meteen mee aan de slag kan.

Met bovenstaande in gedachten kan je de data wel in bv. unix time bijhouden maar aan de app wil je vervolgens wel data van "de dag" aanleveren en met je dus wel gaan omzetten.

Het stoort me wel dat de Watch hierdoor crasht en men hier blijkbaar geen unit test voor heeft. Het is niet de eerste tijd-gerelateerde bug en even je OS op een paar bepaalde datums testen is nu niet zo moeilijk...

Op dit item kan niet meer gereageerd worden.


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True