Z tego co widzę, to excel ma standardowo 364 a nie 360 dnia (analogicznie 365 dla przestępnych). Więc po prostu odejmij daty i dodaj to 0.25, albo 1 jeśli chcesz całkowite.

Edit:
Albo dodaj coś takiego:

=ZAOKR.GÓRA($A1-$B1+(ROK($A1)-ROK($B1)+1)*0,25;0)

Fajnie, fajnie
Różni ludzie proponują rózne wieczne kalendarze, ale może da się ustalić czy rok 1900 był przestępnym?
Wg różnych źródeł, raczej tak.
Jeżeli zatem tak, to analizując co powyżej:
Link 1 - nie istnieje data 1900-02-29
Link 2 - nie pokazuje 29 lutego 1900 na kalendarzu
Link 3 - podaje, że to czwartek, ale 01.03.1900 to też czwartek.

Excel podaje, że to była środa.
Wniosek - jest kupa szmelcu i niewiarygodnych info na necie.
Ktoś (ktosie) stosują jakiś wadliwy algorytm do obliczeń. Wadliwy akurat dla tego 1900 roku :)

Może jeszcze inaczej
=MOD(DZIŚ();7) daje w wyniku (dzisiaj) 5, czyli jak:
1 niedziela
2 = poniedziałek
3 - wtorek
4 - środa
5 = czwartek.
A dzisiaj jest właśnie czwartek.
Od 1 dnia (1900-01-01) minęło dokładnie ... itd

To wg mnie ewidentna wina cyklistów, stoją ci tacy pod budką z piwem, oparci o swoje fury, z rozpiętymi do pasa koszulkami na zamek błyskawiczny, z obcisłymi spodenkami, trzymają w garści kufel zimnego piwa i promują (wzrok szuka samic) niby zdrowy i ekologiczny styl życia.
A człek się potem przed babą musi w domu tłumaczyć, że się jeszcze nie dorobił i nie ma o co swojej ... opierać

Ale jazda, okazuje się, że rok przestępny niekoniecznie występuje co 4 lata
A ja widząć 1904 jako przestępny (w Wikipedii) uznałem, że 1900 musi nim być.
Niezła zagadka histroryczna.
Za wprowadzenie niektórych w błąd I'm sorry.
Artik, szacunek, ale po co czekałeś do 1 w nocy, aż ja z Kaszpirem za pomocą neta wykrwawimy się na śmierć?

To jednak nie była wina cyklistów tylko lotusiarzy. Ale badziew ten Excel

Mimo, że kalendarz gregoriański został wprowadzony kilkaset lat temu i nie jest chroniony żadnymi patentami to niektóre programy Microsoftu mają z nim problem, a szczególnie z datami przestępnymi.

Mogli się o tym przekonać użytkownicy SQL Server 2008 w wersji Customer Technology Preview. 29 lutego 2008 roku jego uruchomienie nie było możliwe. Microsoft o błędzie poinformował na 48 godzin wcześniej zalecając aby tego dnia nie instalować ani nie uruchamiać SQL Servera 2008 i poczekać do 1 marca. Co prawda CTP to wersja testowa, jednak operacje na datach są czymś podstawowym i na takim etapie zaawansowania projektu nie powinny sprawiać problemów.

Tego samego dnia problemy miał też Windows Small Business Server. Nie mógł wygenerować sobie certyfikatu gdyż wstawiana była data 29 lutego 2013 roku.

Zdarzyło się też, że Windows Mobile 2003 przestawił sobie automatycznie datę na 1 marca 2035 przypominając użytkownikowi o 27 latach przegapionych spotkań.

Problem pojawił się też w pocztowym serwerze Exchange. Jeśli 29 lutego administrator dokonał restartu usługi System Attendant niemożliwe stawało się tworzenie i uaktywnianie skrzynek pocztowych.

Z rokiem przestępnym miał problem także Excel, w którym przez 20 lat rok 1900 był rokiem przestępnym mimo, że lata podzielne przez 100 a niepodzielne przez 400 nie są przestępne. Microsoft usprawiedliwiał się, że działo się tak ze względu na kompatybilność z Lotusem 1-2-3. Problem w tym, że w Lotusie takiego błędu nie było. Mimo to Microsoft chciał aby błąd ten znalazł się w standardzie OOXML ze względu, że był w jego oprogramowaniu przez tak długi czas.

Na zakończenie trzeba dodać, że nie tylko Microsoft ma problemy z rokiem przestępnym. Wiedzą o tym osoby urodzone 29 lutego, które mają problemy rejestracją w wielu serwisach internetowych. Do niedawna nie mogły one podać prawdziwej daty urodzenia podczas rejestracji nawet w serwisie YouTube.

Kłopoty Microsoftu z kalendarzem

Mimo, że kalendarz gregoriański został wprowadzony kilkaset lat temu i nie jest chroniony żadnymi patentami to niektóre programy Microsoftu mają z nim problem, a szczególnie z datami przestępnymi.

Mogli się o tym przekonać użytkownicy SQL Server 2008 w wersji Customer Technology Preview. 29 lutego 2008 roku jego uruchomienie nie było możliwe. Microsoft o błędzie poinformował na 48 godzin wcześniej zalecając aby tego dnia nie instalować ani nie uruchamiać SQL Servera 2008 i poczekać do 1 marca. Co prawda CTP to wersja testowa, jednak operacje na datach są czymś podstawowym i na takim etapie zaawansowania projektu nie powinny sprawiać problemów.

Tego samego dnia problemy miał też Windows Small Business Server. Nie mógł wygenerować sobie certyfikatu gdyż wstawiana była data 29 lutego 2013 roku.

Zdarzyło się też, że Windows Mobile 2003 przestawił sobie automatycznie datę na 1 marca 2035 przypominając użytkownikowi o 27 latach przegapionych spotkań.

Problem pojawił się też w pocztowym serwerze Exchange. Jeśli 29 lutego administrator dokonał restartu usługi System Attendant niemożliwe stawało się tworzenie i uaktywnianie skrzynek pocztowych.

Z rokiem przestępnym miał problem także Excel, w którym przez 20 lat rok 1900 był rokiem przestępnym mimo, że lata podzielne przez 100 a niepodzielne przez 400 nie są przestępne. Microsoft usprawiedliwiał się, że działo się tak ze względu na kompatybilność z Lotusem 1-2-3. Problem w tym, że w Lotusie takiego błędu nie było. Mimo to Microsoft chciał aby błąd ten znalazł się w standardzie OOXML ze względu, że był w jego oprogramowaniu przez tak długi czas.

Na zakończenie trzeba dodać, że nie tylko Microsoft ma problemy z rokiem przestępnym. Wiedzą o tym osoby urodzone 29 lutego, które mają problemy rejestracją w wielu serwisach internetowych. Do niedawna nie mogły one podać prawdziwej daty urodzenia podczas rejestracji nawet w serwisie YouTube.

TheRegister

czy rok 1900 był przestępnym? NIE BYŁ.

Od 1582 roku, zgodnie z tym co sobie papież Grzegorz XIII wymyślił i zadekretował (od jego imienia mamy kalendarz gregoriański), w Polsce obowiązuje poniższy algorytm obliczania roku przestępnego:
Function czyPrzestępny(rok As Integer) As Boolean
  If ((rok Mod 4 = 0) And (rok Mod 100 <> 0)) Or (rok Mod 400 = 0) Then
    czyPrzestępny = True
  Else
    czyPrzestępny = False
  End If
End Function Dlaczego więc Excel akceptuje datę 29 lutego 1900?
Jest to świadomy błąd programistów Excela.
Dlaczego świadomie dopuszczono ten błąd?
Ano dlatego, że niejaka firma Lotus (to od niej mamy takie nazwy produktów jak, już zapomniany, Lotus Organizer czy, bardziej znany, Lotus Notes) wypuściła dawno dawno temu (lata 80.) na rynek bubel (pod nazwą 1-2-3), który zakładał, że rok 1900 był przestępny. Ponieważ Lotus w owych czasach był firmą wiodącą w arkuszach kalkulacyjnych, to M$ musiał do niego równać, a nie odwrotnie. Po prostu, M$ stwierdził, że naprawa błędu spowoduje niekombatybilność z arkuszami Lotusa i wolał go pozostawić, jak narazić się użytkownikom. Poniekąd rozumiem stanowisko M$, w tamtych czasach walczył o rynek. Ale wygląda na to, że do us... śmierci arkusze będą obciążone tą skazą genetyczną.
Niby z pogardą odniosłem się do narzędzia Lotusa lecz w pierwszej połowie lat 90. (wersja windowsowa) był to naprawdę wspaniały arkusz. Posiadał funkcjonalność, której Excel (moim zdaniem) dorównał dopiero w wersji 95 (była taka, była
Val(Application.Version) = 7).

Powracając do sprawy, bo się trochę rozmarzyłem,
dzień 1 stycznia 1900 to był PONIEDZIAŁEK (a nie niedziela, jak rzecze "nieomylny" Excel).
Excel błędnie wskazuje dni tygodnia w zakresie dat: 01.01 - 28.02.1900 (przesunięcie o jeden dzień) oraz błędnie akceptuje datę 29.02.1900, której nie było.

Tyle (pre)historii na dziś.

A hudibyk na przyszłość będzie bardziej wylewny w opisie problemu. Prawda?
Choć dzięki jego małomówności w tym wątku, mam nadzieję, że rozwialiśmy sobie trochę wątpliwości.

Artik

.
.
Dziękuję magbo za odzew. Temat obliczania RRSO wydaje się być dosyć ciekawy, więc jeszcze nieco go pociągnę.

Pamiętam, gdy w sierpniu 2001 roku przeczytałem specjalny dodatek do „Rzeczpospolitej” zawierający tekst Ustawy o kredycie konsumenckim oraz pierwsze komentarze do ustawy, zacząłem przeglądać funkcje Excela w nadziei że znajdę taką, która oblicza RRSO. W excelowym opisie funkcji XIRR przeczytałem między innymi:
.
.
Spostrzeżenia
• Program Microsoft Excel przechowuje daty jako kolejne liczby porządkowe, aby można ich było używać w obliczeniach. Domyślnie data 1 stycznia 1900 jest oznaczana liczbą 1, a data 1 stycznia 2008 liczbą 39 448, ponieważ następuje po 39 448 dniach od 1 stycznia 1900. W przypadku komputerów firmy Macintosh program Microsoft Excel używa innego domyślnego systemu dat.
• Liczby w danych zaokrąglane są do liczb całkowitych.
.
.

Pamiętam, że uznałem wtedy iż XIRR nie można użyć do obliczania RRSO. Dlaczego? Bo bankowe plany wypłat i spłat kredytów zawierają kwoty z dwoma miejscami po przecinku, a w Pomocy Excela napisano, że liczby w danych są zaokrąglane do liczb całkowitych co oznacza, że wynik działania XIRR to nie to samo co RRSO (mimo operowania w obu przypadkach tymi samymi danymi).

Teraz, po przeczytaniu postu magbo, zacząłem po raz pierwszy eksperymentować z XIRR i ku mojemu zaskoczeniu stwierdziłem, że przy zmianie wartości na drugim miejscu po przecinku jakiejkolwiek kwoty danych wyjściowych, zmianie ulega wynik funkcji XIRR. A wydawałoby się (w świetle opisu w Pomocy Excela), że ten wynik nie powinien ulec zmianie, o ile nie zmienia się wartość kwoty zaokrąglonej do liczb całkowitych). Z tego, że XIRR jednak reaguje na zmiany wartości kwot (danych wyjściowych) na miejscach po przecinku wynikałoby, że XIRR mogłaby być stosowana do obliczania RRSO.

Jednak wtedy trzeba by mieć świadomość tego, że uzyskiwane wyniki obliczeń będą i tak nie w pełni zgodne z w/w Ustawą, bo XIRR posługuje się wzorem, w którym w mianowniku zawsze występuje 365, a we wzorze Ustawy jest w mianowniku 365 dla lat nieprzestępnych, a 366 dla lat przestępnych.


Ciekaw jestem, co myślicie o takim aspekcie działania funkcji XIRR.

I jak rozumieć informację o zaokrąglaniu do liczb całkowitych zawartą w Pomocy Excela?



P.S. Teraz tak sobie pomyślałem, że może w tekście opisu funkcji w Pomocy Excela jest błąd i zamiast „liczby w danych są zaokrąglane do liczb całkowitych.”, powinno być napisane: „liczby w datach są zaokrąglane do liczb całkowitych.”. Ale to chyba bez sensu, skoro dalej piszą w Pomocy, że daty najlepiej wprowadzać używając funkcji DATA, a ta funkcja (jak wynika z jej nazwy) ma za argumenty wyłącznie liczby całkowite (rok; miesiąc; dzień).
.
.