Discussion:
Miten monta minuuttia?
(too old to reply)
jarkko
2007-02-06 19:22:53 UTC
Permalink
Miten kannattaisi laskea ohjelmassa, että montako minuuttia
on kuukaudessa ja vuodessa?

Googlella haettaessa tulee vastaukseksi:

how many minutes in month
1 month = 43 829.0639 minutes

how many minutes in year
1 year = 525 948.766 minutes

Onko oikein, miten mahdettu laskea?
Vieno Kaino
2007-02-06 19:30:41 UTC
Permalink
Post by jarkko
Miten kannattaisi laskea ohjelmassa, että montako minuuttia
on kuukaudessa ja vuodessa?
how many minutes in month
1 month = 43 829.0639 minutes
how many minutes in year
1 year = 525 948.766 minutes
Onko oikein, miten mahdettu laskea?
On jos hyväksytään Googlen lähtökohta 1 year = 31 556 926 seconds

Vieno Kaino
TaaviUntamo
2007-02-06 19:43:14 UTC
Permalink
Post by Vieno Kaino
Post by jarkko
Miten kannattaisi laskea ohjelmassa, että montako minuuttia
on kuukaudessa ja vuodessa?
On jos hyväksytään Googlen lähtökohta 1 year = 31 556 926 seconds
Mitenkäs google on tuon laskenut? Yhteenlaskulla varmaan, lisäämällä
ykkösen kerran sekunnissa? Nyt ei tarvitse enää muuta kuin miettiä, mikä
vuosi on kysymyksessä. Nehän ovat vähän eri mittaisia.

Ohjelmassa minuutit voi myös laskea yhteenlaskulla. Suorittaa vaan sen
yhteenlaskun tarpeeksi monta kertaa.
Toni
2007-02-07 03:11:20 UTC
Permalink
"TaaviUntamo"
Post by TaaviUntamo
Post by Vieno Kaino
Post by jarkko
Miten kannattaisi laskea ohjelmassa, että montako minuuttia
on kuukaudessa ja vuodessa?
On jos hyväksytään Googlen lähtökohta 1 year = 31 556 926 seconds
Mitenkäs google on tuon laskenut? Yhteenlaskulla varmaan, lisäämällä
ykkösen kerran sekunnissa? Nyt ei tarvitse enää muuta kuin miettiä, mikä
vuosi on kysymyksessä. Nehän ovat vähän eri mittaisia.
Ohjelmassa minuutit voi myös laskea yhteenlaskulla. Suorittaa vaan sen
yhteenlaskun tarpeeksi monta kertaa.
Entäs karkausvuosi ?

-Toni
Kimmo Laine
2007-02-07 05:14:25 UTC
Permalink
Post by jarkko
Miten kannattaisi laskea ohjelmassa, että montako minuuttia
on kuukaudessa ja vuodessa?
Missä kuukaudessa ja missä vuodessa? Kuukauden päivämäärät vaihtelevat
kuitenkin hivenen ja kesä- ja talviaikaan siirryttäessä on yks tunti
enemmän tai vähemmän. Ensin pitää määritellä tarkemmin mitä halutaan
laskea, "kuukausi" ja "vuosi" ovat niin epämääräisiä että täsmällistä
vastausta on mahdotonta antaa ilman tarkennusta. Toki jos lähdetään
vaikkapa pankkimaailmassa käytetyistä määritelmistä joiden mukaan
kuukausi on 30 päivää ja vuosi 360 päivää, luki kalenterissa mitä
tahansa, niin sittenhän tuo on vain kertolaskua: kuukaudessa: 60 * 60 *
24 * 30 ja vuodessa: 60 * 60 * 24 * 360.
--
"En ole paha ihminen, mutta omenat ovat elinkeinoni." -Perttu Sirviö
***@outolempi.net | Gedoon-S @ IRCnet | rot13(***@bhgbyrzcv.arg)
Kimmo Laine
2007-02-07 05:18:04 UTC
Permalink
Post by Kimmo Laine
Post by jarkko
Miten kannattaisi laskea ohjelmassa, että montako minuuttia
on kuukaudessa ja vuodessa?
tahansa, niin sittenhän tuo on vain kertolaskua: kuukaudessa: 60 * 60 *
24 * 30 ja vuodessa: 60 * 60 * 24 * 360.
No niin, sain sitten jostain päähäni että sekunteja kysyttiin. Siis
minuuteista oli kyse, eli yksi 60 * pois kustakin laskusta niin sitten
on minuuteista kyse :)
--
"En ole paha ihminen, mutta omenat ovat elinkeinoni." -Perttu Sirviö
***@outolempi.net | Gedoon-S @ IRCnet | rot13(***@bhgbyrzcv.arg)
Paul Keinanen
2007-02-07 07:29:27 UTC
Permalink
Post by jarkko
Miten kannattaisi laskea ohjelmassa, että montako minuuttia
on kuukaudessa ja vuodessa?
how many minutes in month
1 month = 43 829.0639 minutes
how many minutes in year
1 year = 525 948.766 minutes
Onko oikein, miten mahdettu laskea?
Aurinkovuoden eli trooppisen vuoden pituus on n. 365 vrk 5 h 48 m 46
s, eli tällä pituudella vuodenajat pysyvät paikoillaan, eikä yötön yö
Lapissa ole jonkun ajan kuluttua vaikka maaliskuussa :-).

Jos tuon vuoden pituuden jakaa kahteentoista osaan, päädytään
kuukauden keskipituuteen.

Tuo kummallinen vuodenpituus on aina aiheuttanut kalenterintekijöille
vaikeuksia. Esim. julianisessa kalenterissa on karkausvuosi joka
neljäs vuosi, joten vuoden keskipituudeksi tulee 365 vrk 6 h, eli se
on 11 m 14 s liian pitkä ja vuodenajat vaelsivat pois paikoiltaan.
Gregoriaanisessa kalenterissa ei ole karkausvuotta sadalla jaollisina
vuosilukuina, mutta kylläkin 400 jaollisina. Täsä jää edelleen
virhettä 26 s vuodessa.

Tarkoissa laskuissa pitäisi tosin huomioida karkaussekunnitkin, mutta
niitähän ei voi etukäteen ennustaa.

Paul
MK
2007-02-07 20:53:08 UTC
Permalink
Post by Paul Keinanen
Tuo kummallinen vuodenpituus on aina aiheuttanut kalenterintekijöille
vaikeuksia.
Ja sen on voinut korjata monilla tavoilla. Esimerkiksi lisäämällä
helmikuuhun 30. päivä, kuten muistaakseni Ruotsissa tehtiin joskus
1700-luvulla.
Jouko Koski
2007-02-07 21:37:20 UTC
Permalink
Post by MK
Post by Paul Keinanen
Tuo kummallinen vuodenpituus on aina aiheuttanut kalenterintekijöille
vaikeuksia.
Ja sen on voinut korjata monilla tavoilla. Esimerkiksi lisäämällä
helmikuuhun 30. päivä, kuten muistaakseni Ruotsissa tehtiin joskus
1700-luvulla.
Tämä on varmaan hyvä tietovisailun knoppikysymys. :-)

Noin tosiaan tehtiin, muistaakseni vuonna 1712, ja siinähän oli silloin
Suomikin mukana. Tämä tempaus tehtiin kylläkin sen takia, kun yritettiin
siirtyä asteittain juliaanisesta kalenterista gregoriaaniseen, mutta homma
meni kiville ja palattiin takaisin juliaaniseen kalenteriin. Vuoden 1753
helmikuussa olikin sitten vain 17 päivää ja näin päästiin gregoriaaniseen
systeemiin.

Mutta ohjelmoinnista puheen ollen... Mahtaako minkään ohjelmointikielen
peruskirjasto ottaa huomioon näitä kalenterijärjestelmien muutoksia, etenkään
paikallisia sellaisia? Eivätkä yleiskirjastot taida pahemmin ottaa
karkaussekuntejakaan huomioon, niillä kun ei taida tavanomaisissa laskelmissa
olla merkitystä.
--
Jouko
Ari Makela
2007-02-07 21:36:33 UTC
Permalink
Post by Jouko Koski
Mutta ohjelmoinnista puheen ollen... Mahtaako minkään ohjelmointikielen
peruskirjasto ottaa huomioon näitä kalenterijärjestelmien muutoksia, etenkään
paikallisia sellaisia?
Mielenkiintoinen kysymys. Olen kyllä törmännyt yksittäisiin
sovelluksiin, jotka erittäin rajoitetusti ymmärtävät juliaanisen ja
gregoriaanisen kalenterin eron, mutta ymmärtääkö mikään ohjelmointikieli
edes sitä purkista otettuna?
Post by Jouko Koski
Eivätkä yleiskirjastot taida pahemmin ottaa
karkaussekuntejakaan huomioon,
Ne eivät ole ennustettavissa, joten miten ne voitaisiin ottaa huomioon?
Tietysti esim. JVM:n päivityksissä voitaisiin tuoda historiadataa,
mutta kuten itse totesit niin käytännön merkitystä sillä ei ole.

Nythän on jopa ehdotettu, että karkaussekunneista luovuttaisiin.
--
Ari Makela late autumn -
***@arska.org a single chair waiting
http://arska.org/hauva/ for someone yet to come
-- Arima Akito
Jouko Holopainen
2007-02-07 22:18:10 UTC
Permalink
Post by Ari Makela
Post by Jouko Koski
Mutta ohjelmoinnista puheen ollen... Mahtaako minkään ohjelmointikielen
peruskirjasto ottaa huomioon näitä kalenterijärjestelmien muutoksia, etenkään
paikallisia sellaisia?
Mielenkiintoinen kysymys. Olen kyllä törmännyt yksittäisiin
sovelluksiin, jotka erittäin rajoitetusti ymmärtävät juliaanisen ja
gregoriaanisen kalenterin eron, mutta ymmärtääkö mikään ohjelmointikieli
edes sitä purkista otettuna?
Ei.

Ongelma on se, että nuo siirrot tapahtui erittäin sattumanvaraisesti
maasta y.m. riippuen. Veikkaisin että yhdessä maassa siirryttiin sinne
tänne riippuen oliko minkä "puolueen" taikka uskonnon "jäsen".

Lisäksi silloin ihmisillä ei ollut lainkaan kiinnostusta tietää "monesko
päivä" nyt on - jos joku pappi/nimismies/tms päätti jotain niin se ei
vaikuttanut mihinkään.

Tapahtuiko siis muutos päivänä X jolloin joku päätti vai päivänä Y
jolloin sitä eka kerran käytettiin (lain tms soveltamisesa) vai kun
useampi kuin "kolme" ihmistä tiesi asiasta vai ...
--
@jhol

http://iki.fi/jhol/decss.html
Ari Makela
2007-02-07 22:28:51 UTC
Permalink
Post by Jouko Holopainen
Ongelma on se, että nuo siirrot tapahtui erittäin sattumanvaraisesti
maasta y.m. riippuen.
No juuri tätä tarkoitin sanoilla "erittäin rajoitetusti".
--
Ari Makela late autumn -
***@arska.org a single chair waiting
http://arska.org/hauva/ for someone yet to come
-- Arima Akito
Paul Keinanen
2007-02-08 08:49:28 UTC
Permalink
Post by Ari Makela
Post by Jouko Koski
Mutta ohjelmoinnista puheen ollen... Mahtaako minkään ohjelmointikielen
peruskirjasto ottaa huomioon näitä kalenterijärjestelmien muutoksia, etenkään
paikallisia sellaisia?
Kun käyttöjärjestelmän lokaaliasetuksissa määritellään aikavyöhyke ja
kesä/talviaika säännöt, voisi siellä ihan hyvin määritellä, mikä
kalenterijärjestelmä on käytössä ja koska se on otettu käyttöön. Tämä
on käytännössä paikkakuntakohtainen juttu, koska naapurikaupunki on
saattanut aikaisemmin kuulua eri maahan, joka on käyttänyt eri
kalenterijärjestelmää pitkäänkin.
Post by Ari Makela
Mielenkiintoinen kysymys. Olen kyllä törmännyt yksittäisiin
sovelluksiin, jotka erittäin rajoitetusti ymmärtävät juliaanisen ja
gregoriaanisen kalenterin eron, mutta ymmärtääkö mikään ohjelmointikieli
edes sitä purkista otettuna?
Julianisina päivinähän kalenterilaskut kannattaa sisäisesti tehdä,
jota sentään monet käyttöjärjestelmät sellaisenaan tai modifioidussa
muodossa käyttävät. Sittenhän vain tarvisee tehdä muunnos paikallisen
kalenterijärjestelmän ja julianisten päivien välillä.
Post by Ari Makela
Post by Jouko Koski
Eivätkä yleiskirjastot taida pahemmin ottaa
karkaussekuntejakaan huomioon,
Ne eivät ole ennustettavissa, joten miten ne voitaisiin ottaa huomioon?
Tietysti esim. JVM:n päivityksissä voitaisiin tuoda historiadataa,
mutta kuten itse totesit niin käytännön merkitystä sillä ei ole.
NTP sanomissahan on yksi bitti päällä vähän ennen seuraavan
karkaussekunnin lisäystä, joten siitä pystyy päättelemään ainakin 3 kk
eteenpäin (käytännössä ainakin vuoden, koska karkeussekuntteja on
lisätty korkeintaan yksi vuodessa).

GPS käyttää omaa linearista GPS-aikaansa, jossa ei ole
karkaussekunteja, mutta GPS sanomassa kulkee myös tieto siitä, kuinka
monta sekuntia GPS aika ja UTC aika eroavat toisistaan tällä hetkellä
karkaussekuntien takia.
Post by Ari Makela
Nythän on jopa ehdotettu, että karkaussekunneista luovuttaisiin.
Tämän takana taitavat olla eräät amerikkaliset tahot, joiden mielestä
karkaussekuntti on liian hankala. Eipä silti, samassa maassa erään
osavaltion kansanedustuslaitoksessa yritettin määritellä piin arvoksi
tasan 3, koska se olisi helpottanut laskuja, mutta onneksi tämä
lakimuutos ei mennyt lävitse :-).

Paul
Matti Rintala
2007-02-08 10:58:09 UTC
Permalink
Post by Paul Keinanen
Tämän takana taitavat olla eräät amerikkaliset tahot, joiden mielestä
karkaussekuntti on liian hankala. Eipä silti, samassa maassa erään
osavaltion kansanedustuslaitoksessa yritettin määritellä piin arvoksi
tasan 3, koska se olisi helpottanut laskuja, mutta onneksi tämä
lakimuutos ei mennyt lävitse :-).
Ei siitä piistä yritetty kolmosta tehdä, mutta ilmeisesti 4/1.25 = 3.2, mikä
sekin on riittävän kaukana totuudesta: :)

http://en.wikipedia.org/wiki/Indiana_Pi_Bill
--
------------- Matti Rintala ------------ ***@tut.fi ------------
Painting is the art of inclusion. Photography is an art of exclusion.
Mika Iisakkila
2007-02-08 10:30:44 UTC
Permalink
Post by Ari Makela
Mielenkiintoinen kysymys. Olen kyllä törmännyt yksittäisiin
sovelluksiin, jotka erittäin rajoitetusti ymmärtävät juliaanisen ja
gregoriaanisen kalenterin eron, mutta ymmärtääkö mikään ohjelmointikieli
edes sitä purkista otettuna?
Ohjelmointikielet taitavat lähes läpeensä jättää päivämääräasiat alla
olevan kirjaston tehtäväksi (ainakin jos GNU-kaanonista puhutaan),
joten jos se osaisi esimerkiksi localen perusteella tuon vaihtaa, niin
sittenhän asia toimisi. Luultavasti tuollaista ei vain voida ottaa
yhtäkkiä käyttöön rikkomatta asioita, sillä sen verran monessa
valtiossa vaihdos venyi ensimmäisen maailmansodan yli, ja tulee
vieläkin koko ajan vastaan esim. henkilörekisteriasioissa.

Keskustelun kirvoittamana bongasin Linuxista ncal-komennon, jolle voi
-s -optiolla antaa maakoodin, jonka mukaista kalenterinvaihtopäivämäärää
se käyttää (-p:llä saa listan). FI:lle näkyy olevan (tietenkin) sama
kuin SE:lle, eli 17.2. 1753, jonka jälkeen hypätään maaliskuun alkuun.

Ja manuaalisivun viimeisenä lauseena on "The assignment of Julian -
Gregorian switching dates to country codes is historically naive for
many countries.", mikä tietenkin voi johtua jo siitäkin, että
kalenterisiirtymien maantieteellisillä rajoilla ei paikoin ole
juurikaan tekemistä nykyisten maakoodien kanssa.
--
http://www.hut.fi/u/iisakkil/ --Foo.
Loading...