Hvor mange dage (sekunder)?
Lasse Madsen
Jeg har en "sær" forespørgsel ...
Jeg får fra en server, dags dato opgivet i sekunder fra d. 01/01-1900
klokken 00:00 frem til nu ...
mit problem er at jeg skal bruge hvor sekunder der er gået fra 01/01-1970
klokken 00:00 frem til nu ...
men hvordan regner jeg så ud hvor mange sekunder der er gået fra 01/01-1900
klokken 00:00 til 01/01-1970 klokken 00:00
der er jo også nogle skudår og halløj !?
M.v.h.
Lasse Madsen
Preben Mikael Bohn
> Jeg får fra en server, dags dato opgivet i sekunder fra d. 01/01-1900
> klokken 00:00 frem til nu ...
>
> mit problem er at jeg skal bruge hvor sekunder der er gået fra 01/01-1970
> klokken 00:00 frem til nu ...
>
> men hvordan regner jeg så ud hvor mange sekunder der er gået fra 01/01-1900
> klokken 00:00 til 01/01-1970 klokken 00:00
Du sætter tiden på serveren til 01/01-1970 00:00 og ser hvad den giver,
og trækker det fra i de næste udregninger... :-) Husk at sætte tiden
tilbage (frem) på serveren bagefter... :-) Hvis du ikke har adgang til
serveren (eller den rutine der beregner det) er det naturligvis en anden
sag... :-)
Med venlig hilsen Preben
Aage Andersen
"> men hvordan regner jeg så ud hvor mange sekunder der er gået fra
01/01-1900
> klokken 00:00 til 01/01-1970 klokken 00:00
> der er jo også nogle skudår og halløj !?
>
EXCEL siger 25568 dage = 2209075200 sekunder
mvh Aage
Henry Vest
> men hvordan regner jeg så ud hvor mange sekunder der er gået fra
> 01/01-1900 klokken 00:00 til 01/01-1970 klokken 00:00
> der er jo også nogle skudår og halløj !?
70 år, heraf 17 skudår.
Det giver (70*365+17)*24*60*60 sekunder = 2.208.988.800 sekunder.
--
Henry Vest
Bertel Lund Hansen
>EXCEL siger 25568 dage
Så har du vist regnet den 1/1-1970 med.
--
Bertel
http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/
Peter Makholm
> Jeg får fra en server, dags dato opgivet i sekunder fra d. 01/01-1900
> klokken 00:00 frem til nu ...
>
> mit problem er at jeg skal bruge hvor sekunder der er gået fra 01/01-1970
> klokken 00:00 frem til nu ...
Hvor præcist skal du regne?
Skal du have tiden rigtigt med et sekunds nøjagtighed har du også brug
for at vide om de to servere bruger TAI, UTC eller GPS.
UTC opererer med skudsekunder således at forskellen mellem UTC og en
eller anden form for sand rotationstid (UT1) er under 1 sekund.
TAI (International Atomic Time), som de internationale atomure bruger
er synkroniseret så den 1. januar 1958 var den sammen som UT1.
GPS var synkroniseret med UTC 6. januar 1980, men bruger ikke
skudsekunder.
Således er forskellen mellem disse tre tidsmålinger:
TAI er 32 sekunder foran UTC
TAI er 19 sekunder foran GPS
UTC er 13 sekudner foran GPS
--
Peter Makholm | I congratulate you. Happy goldfish bowl to you, to
pe...@makholm.net | me, to everyone, and may each of you fry in hell
http://hacking.dk | forever
| -- The Dead Past
Torben Brandt
> Aage Andersen skrev:
>
>>EXCEL siger 25568 dage
>
> Så har du vist regnet den 1/1-1970 med.
Nej, snarere 29/2-1900 :)
Excel påstår at år 1900 er skudår, hvilket er forkert.
mvh Torben
Aage Andersen
"Aage Andersen" <aaa(REMOVE)@email.dk> skrev i en meddelelse
news:c5m630$23i3$1...@news.cybercity.dk...
Sorry. EXCEL tror at år 1900 er skudår men det er det ikke i den
gregorianske kalender.
det rigtige resultat er 25567 dage = 2208988800 sekunder.
Mon Bill Gates giver mig pengene tilbage for EXCEL?.
Aage
Preben Mikael Bohn
> Således er forskellen mellem disse tre tidsmålinger:
> TAI er 32 sekunder foran UTC
> TAI er 19 sekunder foran GPS
> UTC er 13 sekudner foran GPS
I det ovenstående er det ret vigtigt i to af tilfældene af specificere
_hvornår_ det var på denne måde... :-)
Med venlig hilsen Preben
Michael Berg
> 70 år, heraf 17 skudår.
>
> Det giver (70*365+17)*24*60*60 sekunder = 2.208.988.800 sekunder.
Nogen der ved hvornår man beregner skudsekund og hvor ofte det sker?
Da de fleste servere har en eller anden form for tidssynkronisering med
diverse atomure vil det formentlig være relevant at indregne skudsekunder i
beregningen også.
/Michael
Jeppe Stig Nielsen
>
> "Lasse Madsen" <l...@h-tech.dk> writes:
>
> > Jeg får fra en server, dags dato opgivet i sekunder fra d. 01/01-1900
> > klokken 00:00 frem til nu ...
> >
> > mit problem er at jeg skal bruge hvor sekunder der er gået fra 01/01-1970
> > klokken 00:00 frem til nu ...
>
> Hvor præcist skal du regne?
>
> Skal du have tiden rigtigt med et sekunds nøjagtighed har du også brug
> for at vide om de to servere bruger TAI, UTC eller GPS.
Mon ikke den pågældende server opererer med præcis 86400 sekunder per
kalender-døgn? Det er vist det almindeligste. Det betyder at fx at
skudsekunder (systemet fik sin nuværende udformning i 1972, men der
var et andet atomtidssystem før) ikke tælles med i den store sum af
sekunder siden den faste referencedato.
Sådan opfører unix-systemet på min pc sig:
[jeppesn@localhost ~]$ date -d '01 jan 1970 utc' +'%s'
0
[jeppesn@localhost ~]$ date -d '01 jan 1982 utc' +'%s'
378691200
[jeppesn@localhost ~]$ date -d '01 jan 1994 utc' +'%s'
757382400
Man ser at skudsekunder ikke tælles med.
Desværre kan man ikke gå helt tilbage til år 1900 (der er vist ikke
bits nok), men det er tæt på:
[jeppesn@localhost ~]$ date -d '01 jan 1902 utc' +'%s'
-2145916800
Så mangler man bare de første to ikke-skudår, nemlig
2*365*86400 sekunder = 63072000 sekunder
Det ønskede tal er vel derfor 2145916800 + 63072000 = 2208988800.
Det var jo også det Henry udregnede på en simpel måde.
--
Jeppe Stig Nielsen <URL:http://jeppesn.dk/>. «
"Je n'ai pas eu besoin de cette hypothèse (I had no need of that
hypothesis)" --- Laplace (1749-1827)
Jeppe Stig Nielsen
>
> > Det giver (70*365+17)*24*60*60 sekunder = 2.208.988.800 sekunder.
>
> Nogen der ved hvornår man beregner skudsekund og hvor ofte det sker?
Du kan finde nogle links på denne side:
http://maia.usno.navy.mil/
>
> Da de fleste servere har en eller anden form for tidssynkronisering med
> diverse atomure vil det formentlig være relevant at indregne skudsekunder i
> beregningen også.
I perioden 1900-1970 har der været flere forskellige definitioner på
sekundet og systemer til at sikre at ures gang svarede til en eller
anden form for astronomisk tid. Men der er ikke megen tvivl om at det
korrektions-led Lasse skal bruge, simpelthen er ±2.208.988.800.
Og husk: Plancks konstant (en forløber for kvantemekanik som er en
forudsætning for atom-ure) var ikke kendt 1/1-1900; det blev den først
senere på året ...
Bertel Lund Hansen
>Excel påstår at år 1900 er skudår
Hrmpf.
>hvilket er forkert.
Ja.
Martin Larsen
> Torben Brandt skrev:
>
> >Excel påstår at år 1900 er skudår
>
> Hrmpf.
>
> >hvilket er forkert.
>
> Ja.
>
DOS kørte i adskillige år med en bug, hvor datoen ikke skiftede
ved midnat. - En nærmest katastrofal fejl!
Problemet her findes ikke hos Macintosh excel. Her har man
valgt at starte ved 1904! (Det er til grin - men svinene laver penge)
Mvh
Martin
Kristian Damm Jensen
> Hej,
>
>> 70 år, heraf 17 skudår.
>>
>> Det giver (70*365+17)*24*60*60 sekunder = 2.208.988.800 sekunder.
>
> Nogen der ved hvornår man beregner skudsekund og hvor ofte det sker?
Der findes ingen fast formel og rytme for skudsekunder.
--
Kristian Damm Jensen damm (at) ofir (dot) dk
Tragedy is when I cut my finger. Comedy is when you fall into an open
sewer and die. -- Mel Brooks
Preben Mikael Bohn
> Nogen der ved hvornår man beregner skudsekund og hvor ofte det sker?
Man beregner det ikke, men kigger på jordens aktuelle
rotationshastighed/rotation i forhold til TAI. Da Jordens rotation ikke
kan forudsiges nøjagtigt i særlig lang tid, kan man ikke bestemme
(endnu, hvis nogensinde) en formel for hvornår skudsekunder skal tilføjes.
Med venlig hilsen Preben
Sven Nielsen
<aaa(REMOVE)@email.dk> says...
> Mon Bill Gates giver mig pengene tilbage for EXCEL?.
Hvis du har købt varen for nylig så har du to års reklamationsret. Gå til
forhandleren og bed om at få fejlen rettet inden for en rimelig tid.
Ellers må handlen jo gå tilbage. Det siger loven.
Med venlig hilsen Sven.
PEHnews
"Kristian Damm Jensen" <REdam...@ofir.dk> skrev i en meddelelse
news:c5mlir$3ao52$1...@ID-146708.news.uni-berlin.de...
> Der findes ingen fast formel og rytme for skudsekunder.
>
>
> --
> Kristian Damm Jensen damm (at) ofir (dot) dk
> Tragedy is when I cut my finger. Comedy is when you fall into an open
> sewer and die. -- Mel Brooks
Hvor regelmæssig er størrelsen årets længde egentlig?
Jeg tænker på, at jordbanens ellipticitet jo ændrer sig mere eller mindre
regelmæssigt!
M.v.h.
Poul Evald Hansen
Henrik
<na...@domain.invalid> wrote:
>Excel påstår at år 1900 er skudår, hvilket er forkert.
På http://support.microsoft.com/default.aspx?scid=kb;en-us;106339
(Knowledge Base-artikel - 106339) er der en nærmere forklaring hvorfor
der er sådan og samt en workaround.
Peter Jensen
>> Mon Bill Gates giver mig pengene tilbage for EXCEL?.
>
> Hvis du har købt varen for nylig så har du to års reklamationsret. Gå
> til forhandleren og bed om at få fejlen rettet inden for en rimelig
> tid. Ellers må handlen jo gå tilbage. Det siger loven.
Held og lykke siger jeg bare ... Det er svært nok bare at få pengene
tilbage for den Windows der var på en ny computer, selv om det første
man gør er at slette den.
--
PeKaJe
Join the Navy; sail to far-off exotic lands, meet exciting interesting
people, and kill them.
Peter Makholm
> Mon ikke den pågældende server opererer med præcis 86400 sekunder per
> kalender-døgn? Det er vist det almindeligste.
NTP (som er det almindeligste til at synkroniserer tid i min verden)
regner vist nok rigtig nok med døgn der er 86400 sekunder, men det
hænder at der er et sekund der optræder to gange efter hinanden.
--
Peter Makholm | What if:
pe...@makholm.net | IBM bought Xenix from Microsoft instead of buying
http://hacking.dk | DOS?
Peter Makholm
> Nogen der ved hvornår man beregner skudsekund og hvor ofte det sker?
Som sagt så beregner man det ikke, men det sker når man opdager at
forskellen mellem UTC og UT1 overstiger 1 sekund.
Min standardhenvisning vedrørende skudsekunder er
http://tycho.usno.navy.mil/leapsec.html
--
Peter Makholm | I laugh in the face of danger. Then I hide until
pe...@makholm.net | it goes away
http://hacking.dk | -- Xander
Peter Makholm
> I det ovenstående er det ret vigtigt i to af tilfældene af specificere
> _hvornår_ det var på denne måde... :-)
Sådan er det *nu*. Der har ikke været indsat skudsekunder siden
1. januar 1999.
--
Peter Makholm | Emacs is the only modern general-purpose
pe...@makholm.net | operating system that doesn't multitask
http://hacking.dk |
Bertel Lund Hansen
>På http://support.microsoft.com/default.aspx?scid=kb;en-us;106339
>(Knowledge Base-artikel - 106339) er der en nærmere forklaring hvorfor
>der er sådan og samt en workaround.
Workarounden forklarer hvordan man korrigerer i hånden. Og så
introducerer den et smart datosystem uden fejlen, det såkaldte
1904-system. Det melder nemlig fejl hvis man prøver at gå tilbage
før 1904 ...
Henning Makholm
> Og så introducerer den et smart datosystem uden fejlen, det såkaldte
> 1904-system. Det melder nemlig fejl hvis man prøver at gå tilbage
> før 1904 ...
Mener den også at 2100 vil være skudår?
--
Henning Makholm "The Board views the endemic use of PowerPoint
briefing slides instead of technical papers as an
illustration of the problematic methods of technical communicaion at NASA."
Bertel Lund Hansen
>Mener den også at 2100 vil være skudår?
Det omtaler siden klogeligt nok ikke. Jeg vil æde min gamle hat
på at den regner sådan.
Martin Larsen
"Bertel Lund Hansen" <nosp...@lundhansen.dk> skrev i en meddelelse news:6cqv709ijbol7dd4c...@news.stofanet.dk...
> Henning Makholm skrev:
>
> >Mener den også at 2100 vil være skudår?
>
> Det omtaler siden klogeligt nok ikke. Jeg vil æde min gamle hat
> på at den regner sådan.
>
28-2-2100 er søndag og 1-3-2100 er mandag
Mvh
Martin
Jeppe Stig Nielsen
>
> > Mon ikke den pågældende server opererer med præcis 86400 sekunder per
> > kalender-døgn? Det er vist det almindeligste.
>
> NTP (som er det almindeligste til at synkroniserer tid i min verden)
> regner vist nok rigtig nok med døgn der er 86400 sekunder, men det
> hænder at der er et sekund der optræder to gange efter hinanden.
Hvis man gemmer en fil mens skudsekundet forløber, så kommer den til
at se ud som om den har samme alder som en fil der er gemt i løbet af
det sekund der gik umiddelbart forud for skudsekundet.
Hvis man trækker aldrene for to filer fra hinanden, så får man kun
antallet af ikke-skudsekunder mellem de to tidspunkter. Den sande,
fysiske tid kan kun findes ved at slå op i en historisk tabel over
skudsekunder i perioden.
Et link: http://www.sciencedaily.com/encyclopedia/unix_epoch
Bertel Lund Hansen
>Sender du et foto på dk.binær?
Nej.
>28-2-2100 er søndag og 1-3-2100 er mandag
Godt jeg ikke har en gammel hat ... Har lige testet det, og det
er korrekt nok - også med default 1900-datosystem.
Martin Larsen
>
> Godt jeg ikke har en gammel hat ...
Snyder!
Mvh
Martin
Jeppe Stig Nielsen
>
> Som sagt så beregner man det ikke, men det sker når man opdager at
> forskellen mellem UTC og UT1 overstiger 1 sekund.
Mere præcist formuleret: Den numeriske forskel mellem UTC og UT1 må
(helst) ikke overstige 0,9 sekunder. Man laver prognoser over denne
differens' forløb ét år frem i tiden, se
ftp://maia.usno.navy.mil/ser7/ser7.dat (skal læses som alm. tekstfil)
Hvis prognosen ved begyndelsen af et halvår (januar eller juli) tyder
på at |UT1-UTC| vil komme væsentligt over 0,5 sekunder, indfører man
et skudsekund (der i teorien også kan være et »negativt skudsekund«,
altså overspringelse af et sekund) som så bliver indsat ved udgangen
af det pågældende halvår.
Skudsekunderne varsles altså små seks måneder i forvejen.
Peter B. Juul
> Godt jeg ikke har en gammel hat ... Har lige testet det, og det
> er korrekt nok - også med default 1900-datosystem.
Hvis du lover at æde den, så har jeg en, jeg kan sende dig.
--
Peter B. Juul, o.-.o "Og hvis man vælter en planet
The RockBear. ((^)) alligevel, så smelter den."
I speak only 0}._.{0 -POK
for myself. O/ \O
Bertel Lund Hansen
>Hvis du lover at æde den, så har jeg en, jeg kan sende dig.
Gud fri mig for mine venner! Mine fjender skal jeg nok selv
klare.
Anders Thorsby
> Således er forskellen mellem disse tre tidsmålinger:
> TAI er 32 sekunder foran UTC
> TAI er 19 sekunder foran GPS
> UTC er 13 sekudner foran GPS
GPS er 13 sekunder foran UTC
--
best regards
Anders Thorsby
Martin Larsen
> Lasse Madsen:
>
> >men hvordan regner jeg så ud hvor mange sekunder der er gået fra 01/01-1900
> >klokken 00:00 til 01/01-1970 klokken 00:00
> >der er jo også nogle skudår og halløj !?
>
> Man regner om til juliansk dato, som kun tæller dage:
>
> 1-1-1900 kl 00:00 = JD 2.415.021,45833
>
> 1-1-1970 kl 00:00 = JD 2.440.588,45833
>
> Forskellen er således 25.567 dage = 2.208.988.800 sekunder
>
Kun fordi du tager differensen går det godt.
Den julianske kalender skifter kl 12 middag.
Dit tal svarer til kl 23:00
1-1-1900 kl 00:00 er altså 2415020.5
Mvh
Martin
Sven Nielsen
pe...@mail.fjerndissetegndanbbs.dk says...
> Hvor regelmæssig er størrelsen årets længde egentlig?
> Jeg tænker på, at jordbanens ellipticitet jo ændrer sig mere eller mindre
> regelmæssigt!
Eh, jeg har ikke hørt om, at jordbanens ellipticitet ændrer sig. Har du
en henvisning til et sted, hvor man kan læse mere om dette?
Ellers er der en formel for årets længde på
http://scienceworld.wolfram.com/astronomy/TropicalYear.html
Det tropiske år er det, vi normalt forstår ved et år. Ifølge formlen
ændrer længden af et år sig systematisk og altså ikke tilfældigt som med
døgnets længde.
Med venlig hilsen Sven.
Jeppe Stig Nielsen
>
> > Man regner om til juliansk dato, som kun tæller dage:
> >
> > 1-1-1900 kl 00:00 = JD 2.415.021,45833
> >
> > 1-1-1970 kl 00:00 = JD 2.440.588,45833
> >
> > Forskellen er således 25.567 dage = 2.208.988.800 sekunder
> >
> Kun fordi du tager differensen går det godt.
> Den julianske kalender skifter kl 12 middag.
> Dit tal svarer til kl 23:00
Det er jo bare fordi Niels' eller hans software antager at det er mid-
nat dansk tid.
Martin Larsen
>
> Det er jo bare fordi Niels' eller hans software antager at det er mid-
> nat dansk tid.
>
Mvh
Martin
Jeppe Stig Nielsen
>
> > Det er jo bare fordi Niels' eller hans software antager at det er mid-
> > nat dansk tid.
> >
> Den forstod jeg ikke - og kommer vist heller aldrig til.
Ingen grund til pessimisme; jeg forklarer det straks.
Tidspunktet »1-1-1900 kl 00:00« dansk normaltid svarer til den julianske
dato 2415020,4583333...
Dette er et andet tidspunkt end 1-1-1900 kl. 00:00 Greenwich-middeltid,
der svarer til juliansk dato 2415020,5 som du også selv skrev.
Jeg troede det var det der var grunden til Niels' tal. Men nu kan jeg
godt se at Niels' tal ikke er 1 time foran UT, men derimod 23 timer
efter UT. Det svarer derfor ikke til dansk normaltid som jeg troede,
men derimod til en (ret fiktiv) tidszone 23 timer vest for Greenwich.
Henning Makholm
> Eh, jeg har ikke hørt om, at jordbanens ellipticitet ændrer sig. Har du
> en henvisning til et sted, hvor man kan læse mere om dette?
Måske en henvisning til præcessionen (af henholdsvis banebevægelsen og
Jordens egenrotation) der gør at afstanden mellem forårspunkt og
perhelion varierer. Dette burde give anledning til en (kvasi)periodisk
variation i længden af det tropiske år.
> Ellers er der en formel for årets længde på
> http://scienceworld.wolfram.com/astronomy/TropicalYear.html
Det er vist bare en tredjegradsapproksimation fittet til
observationerne. Man kan næppe gå ud fra at den holder
når tredjegradsleddet begynder at dominere.
--
Henning Makholm "I ... I have to return some videos."
Martin Larsen
>
> Eh, jeg har ikke hørt om, at jordbanens ellipticitet ændrer sig. Har du
> en henvisning til et sted, hvor man kan læse mere om dette?
>
http://earthobservatory.nasa.gov/Library/Giants/Milankovitch/
Mvh
Martin
Peter Makholm
> > TAI er 32 sekunder foran UTC
> > TAI er 19 sekunder foran GPS
> > UTC er 13 sekudner foran GPS
> Sidste må vist være omvendt...
> GPS er 13 sekunder foran UTC
Enten det eller også er der nogle relativistiske tidsforskydninger ...
--
Peter Makholm | Wisdom has two parts:
pe...@makholm.net | 1) having a lot to say, and
http://hacking.dk | 2) not saying it
Jeppe Stig Nielsen
>
> Der er åbenbart en fejl i mit program, når klokken sættes til 00:00.
Programmet regnede som om det var 1-1-1900 kl. 24.00 dansk tid ...
Martin Larsen
>
> Nej. Det er ikke juliansk kalender, men juliansk dato, vi taler om.
Nej. Det er nu juliansk dag vi taler om.
"Some people use the term Julian date as synonymous with Julian Day or
Julian Day Number. Such use makes it ambiguous, for which reason is
better to reserve the term Julian date to refer to a date in the Julian calendar."
Mvh
Martin
Martin Larsen
>
> >> Nej. Det er ikke juliansk kalender, men juliansk dato, vi taler om.
>
>
> >Nej. Det er nu juliansk dag vi taler om.
>
Lapsus.
> Et sådant system er juliansk dag,
> som også ofte kaldes juliansk dato i den astronomiske litteratur.
Ja, det stod der også i den engelske kommentar fra Wikipedia.
Grunden til at man valgte middag til at skifte, var at astronomerne
så havde samme dag til deres natlige observationer.
Mvh
Martin
Jeppe Stig Nielsen
>
> Ja, det stod der også i den engelske kommentar fra Wikipedia.
> Grunden til at man valgte middag til at skifte, var at astronomerne
> så havde samme dag til deres natlige observationer.
Til gengæld er problemet flyttet om til dem der bor i nærheden af den
180. længdegrad.
Men i praksis er der vist intet problem. Man bruger jo et »flydende«
decimaltal til tids*punkter*.
Martin Larsen
> Martin Larsen wrote:
> >
> > Ja, det stod der også i den engelske kommentar fra Wikipedia.
> > Grunden til at man valgte middag til at skifte, var at astronomerne
> > så havde samme dag til deres natlige observationer.
>
> Til gengæld er problemet flyttet om til dem der bor i nærheden af den
> 180. længdegrad.
>
til at forestille sig de etnocentricitetsproblemer som vor tids
intellektuelle er så sygeligt optagede af.
Mvh
Martin