On Tue, 2004-05-25 at 05:03, Ordak D. Coward wrote:
> Farsiweb should prepare -- if that is in the scope of FarsiWeb's work
> -- a draft of a recommended practice for implementing date conversion
> involving calendars used in Iran. This document will of course change
> over time, as long as better
On Tue, 2004-05-25 at 01:40, Ordak D. Coward wrote:
> I downloaded and tested a few dates with the Win32 executable of
> Jalali (the one at sourceforge). The bad news is that, the conversion
> is not correct.
> The conversion is wrong for 20 March 2005, and similarly a few other
> dates that should
I recommend augmenting the documentation of any calendar
implementation with a clear description of limitations and range of
accuracy of the implementation. Otherwise, many people -- at least I
was until a few days ago -- are going to get deceived into trying to
assume a 2820 year period is more co
I downloaded and tested a few dates with the Win32 executable of
Jalali (the one at sourceforge). The bad news is that, the conversion
is not correct.
The conversion is wrong for 20 March 2005, and similarly a few other
dates that should convert to 30 Esfand Year YYLP, instead all such
dates conver
On Mon, 2004-05-24 at 10:28, Ordak D. Coward wrote:
> Another way to interpret this email is that Birashk's method fails to
> correctly predict the year 1403, and hence if we use that mehtod, all
> dates in year 1404 will be off by one day. On the other hand, using
> the 33 year period mentioned a
So, to conclude, I think we better don't touch the 33
implementations we have until we've got a real calendar. Just
talking about FarsiWeb of course. Other people are free about
what they choose.
behdad
On Mon, 24 May 2004, Ordak D. Coward wrote:
> I did some more research on the accuracy of
I did some more research on the accuracy of different leap year
algorithms. My conclusion is that unless there is an implementation of
an astronomical algorithm, we SHALL use the 33 year period, as it
gives the best estimates for near future and near past. That is, use
the following:
bool isLeapYea
On Fri, 21 May 2004, Ordak D. Coward wrote:
> I guess the best thing to do:
>
> - is get an archive of the last 50 years of official times of
> vernal equinox, or saal tahveel, and compute the length of
> year for each year. Fit them with linear or quadratic curves.
> Look at Birashk's method
On Fri, 21 May 2004, Ordak D. Coward wrote:
> I was looking at Omid K. Rad's implementation of calendar, and have a
> few comments on calculating leap years.
Thank you ODC for evaluating my code.
> 1. The implemented algorithm uses a 128 year period, although the
> comments say it uses a 2820
On Thu, 20 May 2004 22:30:33 -0400, Behdad Esfahbod
<[EMAIL PROTECTED]> wrote:
>
> On Thu, 20 May 2004, Ordak D. Coward wrote:
>
> > Ordak's 2820 year method:
> > bool isLeap2820ODC = ((683*year+542) % 2820) < 683;
> >
> > in comparison to:
> >
> > Birashk's 2820 year method:
> > bool isLeap2820Bir
On Thu, 20 May 2004, Ordak D. Coward wrote:
> Ordak's 2820 year method:
> bool isLeap2820ODC = ((683*year+542) % 2820) < 683;
>
> in comparison to:
>
> Birashk's 2820 year method:
> bool isLeap2820Birashk = ((year % 2820) == 474) ||
> (((31 * ((year+2345) % 282
I was looking at Omid K. Rad's implementation of calendar, and have a
few comments on calculating leap years.
1. The implemented algorithm uses a 128 year period, although the
comments say it uses a 2820 year period. While I need to ask for this
discrepancy be resolved, it is important to understa
12 matches
Mail list logo
