Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' 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

Door , , 82 reacties
Bron: Infoworld

Een energiebesparingswet die de zomertijd in de Verenigde Staten met een maand verlengt, zal waarschijnlijk binnenkort door het Congres worden aangenomen. De zomertijd zou dan twee weken eerder beginnen en twee weken later ophouden. Zij die de wet steunen, verwachten er 100.000 vaten olie per dag mee te besparen.

Voor programmeurs kan dit wel eens een hoop werk betekenen. Tegenwoordig zetten computers en andere elektronische apparatuur met een klok aan boord deze doorgaans automatisch op zomertijd en weer terug, en al die apparatuur zal opnieuw moeten worden geprogrammeerd. Tal van programmeurs en systeembeheerders zijn al jaren aan het worstelen met hulpprogramma's rond de zomertijd. Cisco Systems heeft bijvoorbeeld tal van pagina's met technische informatie over het verhelpen van zomertijdproblemen en het discussieforum van Oracle staat vol met posts van programmeurs die hulp zoeken bij problemen met de zomertijd.

De IT-industrie heeft overigens nog tijd genoeg om zich op de verandering voor te bereiden. Als de wet dit jaar wordt aangenomen, zal hij pas in 2007 in werking treden. Met veranderingen aan de zomertijd doen de VS het trouwens nog kalm aan, vergeleken met sommige andere landen. Dit wordt de eerste verandering sinds 1987. Brazili bijvoorbeeld verandert de data ieder jaar en Isral deed dat tot dit jaar ook. Chili begon in 1987 wat later vanwege het bezoek van de paus in april. Sydney begon in 2000 juist wat eerder vanwege de daar gehouden Olympische Spelen. Dat bezorgde Microsoft pas echt overwerk.

Ook hier zullen de meeste getroffen systemen waarschijnlijk Windows draaien. Microsoft verwacht geen moeilijkheden. 'We weten dat het eraan komt en we zullen zorgen dat Windows de verandering soepel afhandelt', aldus het bedrijf. 'Soepel' betekent echter niet altijd foutloos, en diverse Windows-versies hebben al problemen met zomertijd gehad. Zeker is in ieder geval dat het niet de potentie heeft zoveel narigheid te veroorzaken als het millenniumprobleem. Opportunistische programmeurs zien hier al goede kansen in op lucratieve klussen zonder veel risico. 'Als er geen echt gevaar is, kan je ook niet falen.'

IBM Linux-klokje
Moderatie-faq Wijzig weergave

Reacties (82)

Ik snap het probleem eigenlijk niet zo goed. Tenminste, ik snap wel dat het veel werk is, maar in de meeste gevallen zal het beginnen en eindigen van de zomertijd toch gewoon een variabele zijn die gewoon in te stellen is?
Toch moet je iets verder kijken, je kan niet zo maar een algemene variabel aanpassen, want dan kloppen ineens alle oude zomertijden niet meer.

Programmeur functies zoals DateDiff komen dan in de problemen, als je op 'uren' gaat kijken. Als het programma dus gebruik maakt van het OS voor de omschakeldatums is er geen probleem, echter als het zelf geprogrammeerd is, dan zullen er dus problemen komen.
Programmeur functies zoals DateDiff komen dan in de problemen, als je op 'uren' gaat kijken.
Dat soort functies horen met GMT/UTC tijden te werken, niet met 'gecorrigeerde' tijden.
Ja het is een variabele, maar "normaal" is het zomertijd iets dat de eerste zondag van een maand begint en de laatste zondag van een maand eindigd.
Vandaar dat (ik soms ook) en anderen een fout gemaakt hebben om zoiets hard coderen, waardoor nu met een verandering alles in de soep loopt :(
Stom, maar soms heb je de tijd niet om het in variabelen om te zetten. (Druk om een project af te krijgen)
Als je daar vanuit gaat ben je sowieso fout bezig. Het eerste zondag en laatste zondag is Europees en Amerikaans, tal van andere landen doen het net een zondag eerder(de laatste van de vorige maand) of later, de eerste van de volgende maand dus. Of het valt samen met een religieuze feestdag. Er zijn zoveel mogelijkheden dat het op die manier sowieso fout gaat.
Als je het wel netjes met variabelen hebt gedaan is het een kwestie van secondes werk. Wederom een goed voorbeeld waarom je alles zo netjes en flexibel mogelijk op moet zetten.
Pst: deze wet geldt alleen voor Amerika, dus niet voor Europa. :Y)
ja leuk maar als ik mijn pc hier om wat voor reden dan ook omzet op New York tijdzone of voor mijn part de LA tijdzone verwacht ik nog steeds dat het werkt hier ondanks dat ik in europa zit. :z
Ik kan me voorstellen dat vooral in de wat oudere programma's dit soort zaken hard gecodeerd zijn. 'Vroegah' wilde men immers besparen op de bits en bytes en de oudere programma's zijn juist de programma's die last krijgen van dit soort besluiten. Denk bv. aan grote bedrijven die al jarenlang hetzelfde programma gebruiken om een-of-andere functie te vervullen waarbij de tijd belangrijk is.
Dit slaat nergens op wat je zegt.

De tijdnotatie verandert niet, de datumnotatie verandert niet.

Alleen de zomertijd begint eerder en eindigt later.

Wat heeft dat in Godsnaam met de notatie te maken?
Ik zie in die post niets staan over notatie. Pven bedoelt dat die oude programma's geen mogelijkheid hebben om eerder of later met zomertijd te beginnen omdat dat in het programma vast ligt. Op die manier kun je het programma kleiner houden, maar het wordt er veel minder flexibel van.
'Vroegah' wilde men immers besparen op de bits en bytes
Een veldlengte dient nu eenmaal vooraf gedefinieerd te worden en alles wat men teveel neemt wordt per record te veel genomen. Typische datumlimieten voor Unix-achtige systemen zijn vanaf 1902 tot 2038.

Zieook: http://home.netcom.com/~rogermw/Y2038.html

<edit>Typo</edit>
Ja, en daarom is op 64-bit systemen time_t al een 64-bit getal :) Kunnen we nog een paar millenia door :)

Truc is dus om vr 2038 alle 32-bits machines f te upgraden (64-bit time_t erin) f ze gewoon uit te faseren.

En wees nou eens eerlijk, wie gebruikt er nou nog dagelijks computers van 33 jaar oud :)
> En wees nou eens eerlijk, wie gebruikt er nou nog dagelijks computers van 33 jaar oud

Had de Computable laatst niet een prijsvraag over de oudste in gebruik zijnde computer ? Ik meen dat dat er nog meerdere IBM PC's (4.77 MHz 8088 met cassette interface) in gebruik waren en dat is 1981 dus 24 jaar oud....
Het is ook een kwestie van OF een slordige snelle hack ervoor maken of het fundamenteel oplossen. Als je de eerste aanpak hebt gekozen en er komen veranderingen zoals hier dan BLIJF je bezig. Bij een fundamentele oplossing die wat groter van omvang zal zijn is wordt het gewoon een kwesrie van een tabelletje aanpassen.
Overigens mogen de zomertijd van mij opheffen...

<offtopic>NB een leuk ezelsbruggetje om te onthouden of de klok voor of achteruiit moet is dit: "fall (herfst)backwards en spring (lente) forward" even aangenomen dat iedereen naar achteren valt en vooruit springt :-)

Ton
"<offtopic>NB een leuk ezelsbruggetje om te onthouden of de klok voor of achteruiit moet is dit: "fall (herfst)backwards en spring (lente) forward" even aangenomen dat iedereen naar achteren valt en vooruit springt"

leg dit ook even uit aan die gozert van KopSpijkers.... :+
Hahahaha, wat een onzin. Dit is weer een mooi voorbeeld van wat voor idioten aan de macht zijn.
Zomertijd veranderen heeft echt geen effect op de power consumptie. Zeker niet in een energie verspillend land as de USA.
Ok, misschien besparen ze op gloeilampen. maar de productie machines draaien 24/7, vliegtuigen vliegen ook de hele dag door, etc.

(PS, NTP)
Waar ze op doelen is vooral het menselijk gedrag met betrekking tot de zomer tijd.

Dus vooral verlichting! En dat kan een behoorlijk bedrag zijn want de meeste mensen gebruiken nog altijd gloeilampen en die dingen zijn een van de aparaten met zo een beetje het laagste rendament, ze zijn zelfs nog beter als kagel in te zetten dan als lamp!!!
Dus ik denk dat die besparing behoorlijk hoog kan zijn.

En NTP kan geen oplossing zijn omdat dit alleen GMT tijd levert en je zelf daar een tijdzone aan moet koppelen en de zomertijd afwijking moet je daar ook zelf aan koppelen met behulp van een offset.

In de winter leeft Nederland bijvoorbeeld in GMT+0100 en in de zomer in GMT+0200 en die offset die je mee moet geven is het probleem!
(PS, NTP)
NTP helpt hier niet. NTP zorgt er alleen voor dat de absolute tijd goed is, niet dat je offset tov daarvan (en dat is wat bij zomertijd verandert) klopt.
alle beetjes helpen...
Maak dan energie zuinige autos verplicht. Dat scheelt enorm veel en zorgt voor een redelijke economie boost omdat men nieuwe autos moeten kopen.
Dat zou betekenen dat iedereen met te weinig geld voor een nieuwe auto niet langer auto mag rijden.

minder vervuiling, dat wel, maar of dat opweegt tegen de ontevreden mensen :?
Dan kunnen ze beter op andere dingen besparen dan dit soort (in mijn ogen) rare wetten te verzinnen.

Harde cijfers kan ik je uit m'n hoofd niet geven, maar ik weet wel dat Amerika een enorme hoeveelheid energie slurpt met dingen die ze vl zuiniger kunnen maken. Neem bijvoorbeeld vrijwel alle auto's die ze veel zuiniger kunnen maken, maar dit simpelweg niet doen omdat de benzine daar maar een appel en een ei kost.

Het idee om te bezuinigen vind ik leuk, maar de uitwerking is gewoon prutserig.
Grapjas, en jou moeten we wel serieus nemen?
Denk je nu echt dat een land al die problemen zo maar wil aangaan zonder er iets voor terug te krijgen?
Men gaat dus een wet aanpassen, zodat er economisch voordeel wordt behaald bij de olie. Helaas vergeten ze de economische nadelen, programmeurs kosten immers ook geld. :?

Wat een raar besluit ...
Het gaat de Amerikanen niet alleen om kosten, maar ook om milieu en buitenland politiek (minder afhankelijk worden van landen zoals Saoudi Arabi en Venuzuela)
Klopt.
Daarom is Amerika ook 1 van de grondleggers van het Kyoto accoord.
Ik denk dat dit een vorm van sarcasme is ? :?
Waarom wil Bush er dan niets van weten ?

http://www.newsmax.com/archives/articles/2001/3/29/164418.shtml

Grondlegger ten tijde van Clinton, afbraak ten tijde van Bush. Maarjah, das wel met alles eigenlijk :)
Grondleggers? En het vervolgens zelf niet willen ondertekenen zeker?

Amerika is een van de grootste schenders van het Kyoto akkoord!
offtopic:
@Green.Velvet
[quote]

Hier in Belgie bijvoorbeeld hebben ze een tijd geleden in het kader van Kyoto met veel boe en ba besloten de kerncentrales te sluiten. Alleen waren ze vergeten dat er momenteel geen deftige alternatieven zijn.
[/quote]
Men vergeet vooral dat er wl alternatieven zijn voor energiewinning en geen oplossingen voor het kernafval.
Dat die beslissing met Kyoto te maken had is overigens manifest onwaar, want kernenergie zorgt niet voor een verhoogde CO2-uitstoot (i.t.t. klassieke kolencentrales).
[quote]
Resultaat : in alle stilte is men de datum van die sluiting hoe langer hoe meer aan het vooruitschuiven...
[/quote]
Dat heeft niets met realpolitik te maken maar alles met politieke opportunisme.


Edit: formatting
Omdat de USA zelf ook de enigste is die de negatieve economische gevolgen op lange termijn doorziet.

Kyoto is op zich goed, maar niet op de manier dat ze het nu zoeken door te drukken. Dat is voor zowat elk industrieel land bijna nefast voor het bestaan van hun activiteiten.

Hier in Belgie bijvoorbeeld hebben ze een tijd geleden in het kader van Kyoto met veel boe en ba besloten de kerncentrales te sluiten. Alleen waren ze vergeten dat er momenteel geen deftige alternatieven zijn.

Resultaat : in alle stilte is men de datum van die sluiting hoe langer hoe meer aan het vooruitschuiven...

Het principe van Kyoto is goed, maar het moet realistisch blijven...
Werkgelegenheid schaadt de economie? :Z
Of dacht je dat alle Amerikaanse bedrijven Japanse software draaiden, zodat ze allemaal buitenlandse programmeurs moeten binnen halen om de problemen te fixen?
Een aantal uren op de dag meer zon, zodat je minder energie verbruikt scheelt toch echt wel iets meer dan de kosten van een programmeur die 1x ergens iets moet aanpassen.
Zo'n atoomklok in elke pc inbouwen dat je signaal vanuit frankfurt krijgt altijd handig :)
Totdat de Duitse autoriteiten besluiten op eigen houtje de tijdsinterpretatie te veranderen, zoals men nu in de V.S. aankondigt te gaan doen... }>
Dan snap je het niet.... lees het nog eens door.
Dat signaal uit Frankfurt blijft altijd de GMT tijd doorgeven, zomertijd of niet.. jouw OS beslist zelf welke tijd wordt aangegeven,
NOT,
Het DCF77 bevat wel degelijk de een trigger voor de zomertijd, en dus ben je hiermee afhankelijk van de door Ze Germanz opgelegde zomertijd.
Maar sinds ze onze vrienden zijn zou dat geen probleem moeten geven...
Ik heb sterk de indruk dat het hier niet alleen gaat om het omschakelen van zomer- naar wintertijd en weer terug. Anders snap ik niet waar Oracle mensen problemen over maken. Oracle houdt nl zelf helemaal geen datum bij. Die leest ie uit van het OS. En als ik zo handig ben om mijn pc's te syncen met NTP of een atoomklok, moet je toch van een bedrijf verwachten dat zij hun OS wel op tijd kunnen laten overschakelen. En als je OS op tijd loopt, loopt Oracle vanzelf op tijd. En volgens mij alle programmatuur die op dat OS loopt.

Wat is dus het probleem hier? Gaat het soms om programmatuur die analyses doet op data en daarvoor ook tijd met tijden werkt oid? Ik kan me nl niet veel bij dit probleem voorstellen.
Het lijkt mij dat het synchroniseren van alle computers binnen een groot bedrijf op 1 moment moet gebeuren, omdat je anders problemen kunt krijgen omdat de ene computer een andere tijd heeft dan de andere, waarbij ik denk aan conflicten met databases.
Misschien niet heel moeilijk, maar het moet natuurlijk wel helemaal goed gebeuren. Als 1 programma op een bedrijf niet meewerkt, lijkt het mij lastig.
Gelukkig kun je 2 jaar voorbereiden(2007).
Daarom gebruik je als slimme programmeur bij INSERT query's niet de lokale tijd, maar de tijd van de server...
MySQL: UNIX_TIMESTAMP() of NOW().

Scheelt je een hoop gezeik.. ;-)
Of het nu enorme onzin is of niet om dit in te voeren. Het levert wel weer meer werk op. Dit is natuurlijk goed voor de werkgelegenheid in de IT en misschien is het wel een goede impuls voor de IT markt in de hele wereld. De Verenigde Staten zijn immers een voortrekker in de IT markt.

En misschien helpt het het milieu inderdaad ook nog eens keer, ookal zitten de meeste programmeurs 99% van de tijd achter hun computer en zullen ze er zelf niks van merken :P
Daar zit echt niemand meer op te wachten: eerst massaal mensen omscholen, om vervolgens als het werk af is met een gigantisch overschot van overbodige mensen te blijven zitten. Volgens mij creeer je dan een beetje een effect als de internet zeepbel. Groei moet structureel zijn, niet incidenteel.

offtopic:
En groei is volgens mij ook niet waar het altijd om moet gaan. Als we al onze vakantiedagen inleveren hebben we ook een enorme groei, maar of we daar blij van worden?
100.000 vaten per dag besparen, dat zet lekker zoden aan de dijk, op een dagelijkse consumtie van ruim 20 miljoen vaten.
hee alle beetjes helpen, je moet toch ergens beginnen..
20 miljoen vaten aan pakweg 50$ per vat (ik zeg maar wat), das 1miljard dollar. Da's toch netjes, niet?
maak daar op dit moment maar $61 van
en dat voor maar 1 maand.
dus 3 miljoen vaten op een jaar van 7300 vaten ofwel 0,041% per jaar
ach alle beetjes helpen :o
Maar ligt het nou aan mij, zomertijd 2 weken langer maken doet toch niets aan het energie verbruik, mensen zetten het licht niet altijd precies om bv 18:00 aan of uit, maar meestal juist als het gaat schemeren, en dat blijft natuurlijk altijd op dezelfde 'tijd'..
Ja, maar ze gaan meestal elke dag om ongeveer dezelfde tijd naar bed, ivm aanvangstijd van hun werk. Door zomertijd moeten ze eerder naar bed, en doen ze dus eerder het licht en de TV / computer uit.

Men kan hetzelfde bereiken door gewoon de werktijden te vervroegen. Dus beginnen om 7 uur i.p.v 8 :)
Het probleem met zomer/winter tijd ligt hem er niet in dat je opeens de tijd moet kunnen aanpassen maar bij systemen zoals order systemen.

Er word op 3:30 order geplaatst, deze word in de que gezet, om 4 uur gaat de tijd een uur terug, is het weer 3 uur. (elke uur moest de order verwerking gaan lopen). Dus om 3 uur probeert met de que van voor 3 uur weg te werken, terwijl die al weg was. En een uur later word pas de order van 4 uur weggewerkt.

Dit is een voorbeeld van een use case, er zijn veel meer van dit soort gevallen die erg moeilijk aan te passen zijn. en al jaren werken.
Ik neem aan dat de servers gewoon op GMT werken, dan heb je dat probleem niet.
Waarom niet het hele jaar zomertijd. Dat scheelt nog meer olie. Dat hoef je maar een keer te patchen en daarna nooit meer.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True