Hi Whit, Many thanks for the link. The Boost options look interesting, although calendar conversion is mentioned in the goals I couldn't see a direct example of it on the website.
I'm not sure how this would be coded, but the general details for the conversion are that the date would have to be split up into day, month and year, then: 1) For year conversion it is relatively easy - Persian calendar is 621 years behind so to get gregorian year from the Persian year add 621; 2) For the months, there are also 12 months in the Persian year but the Persian new year falls on the gregorian date 21st March. 3) For the date (day): the first 6 Persian months have 31 days, the next 5 have 30 and the last month has 29 or 30 depending on if it is a leap year. Incidentally I also just got a reply from Thomas Lumley on the R-sig-epi list, he has written an R wrapper for the c code, message below: --------------------------------------------------------------------------------------------------------------------------------------- I looked at the C code from Project Pluto that Hosseini references, and wrote R wrappers for it. The C and R code are at http://faculty.washington.edu/tlumley/calendars I haven't turned it into a package (anyone who wants to is welcome), and it has only been tested to a limited extent and only on Mac OS. Build the C code with R CMD SHLIB convdates.c date.cpp then source("convdates.R") This sets up an OtherDate class that can hold Persian, Islamic, Hebrew, and the other calendars that the C code supports, with methods to convert to and from Date. It should be possible to translate the C algorithms into straight R with little loss of efficiency, but that looked like more than an hour's work. -thomas Thomas Lumley Assoc. Professor, Biostatistics tlum...@u.washington.edu University of Washington, Seattle ------------------------------------------------------------------------------------------------------------------------------------------- Best wishes, Amy On Wed, Jan 7, 2009 at 5:47 PM, Whit Armstrong <armstrong.w...@gmail.com>wrote: > probably easy to do w/ Boost DateTime > > http://www.boost.org/doc/libs/1_37_0/doc/html/date_time.html > > for which there is already an R package in development: > http://repo.or.cz/w/RBoostDateTime.git > > I'm happy to write a small wrapper to do what you want if you can > offer a pseudocode example of the conversion function. > > -Whit > > > On Wed, Jan 7, 2009 at 12:20 PM, Ted Byers <r.ted.by...@gmail.com> wrote: > > On Wed, Jan 7, 2009 at 10:23 AM, Amy Mikhail <amy.mikh...@googlemail.com > >wrote: > > > >> Dear list, > >> > >> I will shortly have some data that contains numeric dates in the Persian > / > >> Jalali calendar format, which I would like to convert to gregorian. At > the > >> moment there doesn't seem to be a function for this in R, but it would > be > >> great if someone could come up with same - I would attempt it but the > >> algorithm is very complex and this is also way beyond my fairly > rudimentary > >> knowledge of R. > >> > >> How do you feel about mixed language programming? > > > > I don't know anything about Jalali dates, but I took the time to check > and > > found that Perl has modules that handle this (use CPAN or, on windows, > PPM > > to find them). However, like the C code you found, it will convert > values a > > date at a time. I don't know why this would be an issue. > > > > I have never tried to use either C or perl from within R, but if you can > > handle that, it would be trivial to apply these function calls to each > value > > in a vector (or array if you prefer) in functions written in either C/C++ > or > > perl. In both C++ using STL and Perl, that would require only one line > of > > code, and perhaps a couple more in C to manage the required loop if you > > restrict yourself to C, ignoring the benefits of C++. > > > > If I were doing this, I'd do it even before storing the data in my > database, > > or at least before importing it into a dataframe in R, but that is > primarily > > because I am still learning R, having used it for only a few months, > rather > > than a few years using perl and 15+ years using C++. I am so early on my > R > > learning curve that I haven't yet looked at writing code in C++ or Perl > that > > is to be called by R. While I haven't read through it in enough detail > to > > play seriously with it, the method for using such code from with R > described > > in "Writing R > Extensions<file:///C:/Program%20Files/R/R-2.8.0/doc/manual/R-exts.html>" > > seems simple enough. Instead of writing the code to implement your > > 'complex' algorithm, why not just use the code you've found, or that > > available in CPAN (I don't know about you, but I hate reinventing the > > wheel), and create the trivial extension needed following the > instructions > > in "Writing R > Extensions<file:///C:/Program%20Files/R/R-2.8.0/doc/manual/R-exts.html>", > > or do it to the raw data before you import it into R? > > > > HTH > > > > Ted > > > > [[alternative HTML version deleted]] > > > > ______________________________________________ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > -- Amy Mikhail Program Manager, ACTc Afghanistan Malaria Project London School of Hygiene & Tropical Medicine HPRO, Charahi-e-Shahid, Shar-e-Naw, Kabul, Afghanistan Email (Afg): amy.mikh...@googlemail.com Email (UK): amy.mikh...@lshtm.ac.uk Tel (Afg): +93 (0)706 126627 Tel (UK): +44 (0)781 4176107 [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
