Hello I am new to R and I need to convert some dates (numeric format by matlab) to actual dates in R. For instance, Matlab -> 730456 -> >> datestr(730456) ans 02-Dec-1999 R -> library(zoo) > as.Date(730456)[1] "3969-12-03" I don''t not mind the output format but it needs to be right. Many thanks Ed

You need to specify the origin: as.Date(730456, origin = "matlabs origin date") HTH, Josh P.S. Alternately, you may be able to do something like: ## find R''s numeric representation of 02-Dec-1999 and use the difference from Matlabs to offset MatLabROffset <- 730456 - as.numeric(as.Date("1999-12-02")) as.Date(730456 - MatLabROffset) On Sat, Jul 16, 2011 at 8:50 PM, Eduardo M. A. M. Mendes <emammendes at gmail.com> wrote:> Hello > > I am new to R and I need to convert some dates (numeric format by matlab) to actual dates in R. > > For instance, > > Matlab -> 730456 -> >> datestr(730456) > > ans > > 02-Dec-1999 > > R - > >> library(zoo) >> as.Date(730456) > [1] "3969-12-03" > > I don''t not mind the output format but it needs to be right. > > > Many thanks > > Ed > > ______________________________________________ > R-help at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. >-- Joshua Wiley Ph.D. Student, Health Psychology University of California, Los Angeles https://joshuawiley.com/

Hi: The default time origin in R is ''1970-01-01''. as.Date(''1999-12-02'') - as.Date(''1970-01-01'') Time difference of 10927 days Therefore, the difference in days between Matlab''s and R''s origins is 10927 - 730456 [1] -719529 as.Date(-719529, origin = ''1970-01-01'') [1] "000/-12-31" If we try this as an origin,> as.Date(730456, origin = "000/-12-31")Error in charToDate(x) : character string is not in a standard unambiguous format Checking the as.Date() help page, we find the line "Years before 1CE (aka 1AD) will probably not be handled correctly." However, if we add a day, as.Date(730456, origin = ''0000-01-01'') [1] "1999-12-03" which is one day later. So it appears that by subtracting 1 from the Matlab date and using origin ''0000-01-01'' should work. Matlab2Rdate <- function(val) as.Date(val - 1, origin = ''0000-01-01'')> Matlab2Rdate(730456)[1] "1999-12-02" HTH, Dennis On Sat, Jul 16, 2011 at 8:50 PM, Eduardo M. A. M. Mendes <emammendes at gmail.com> wrote:> Hello > > I am new to R and I need to convert some dates (numeric format by matlab) to actual dates in R. > > For instance, > > Matlab -> 730456 -> >> datestr(730456) > > ans > > 02-Dec-1999 > > R - > >> library(zoo) >> as.Date(730456) > [1] "3969-12-03" > > I don''t not mind the output format but it needs to be right. > > > Many thanks > > Ed > > ______________________________________________ > R-help at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. >

On Sat, Jul 16, 2011 at 11:50 PM, Eduardo M. A. M. Mendes <emammendes at gmail.com> wrote:> Hello > > I am new to R and I need to convert some dates (numeric format by matlab) to actual dates in R. > > For instance, > > Matlab -> 730456 -> >> datestr(730456) > > ans > > 02-Dec-1999 >Set the origin to Matlab''s origin like this. Be sure you are using the indicated version of zoo or later:> library(zoo) > packageVersion("zoo")[1] ?1.7.1?> as.Date(730456, origin = "0000-00-00")[1] "1999-12-02" -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com

On Jul 18, 2011, at 14:08 , Gabor Grothendieck wrote:> On Sat, Jul 16, 2011 at 11:50 PM, Eduardo M. A. M. Mendes > <emammendes at gmail.com> wrote: >> Hello >> >> I am new to R and I need to convert some dates (numeric format by matlab) to actual dates in R. >> >> For instance, >> >> Matlab -> 730456 -> >> datestr(730456) >> >> ans >> >> 02-Dec-1999 >> > > Set the origin to Matlab''s origin like this. Be sure you are using > the indicated version of zoo or later: > >> library(zoo) >> packageVersion("zoo") > [1] ?1.7.1? >> as.Date(730456, origin = "0000-00-00") > [1] "1999-12-02"Doesn''t work on a Mac, and in general, I think it depends on a quirk in your OS''s date conversion utilities. What does work for me is> as.Date(730456-1, origin=''0000-01-01'')[1] "1999-12-02" but even this is dubious, since there is no year 0 AD. In Gregorian and Julian calendars, 1 BC continues directly into 1 AD. So, to be sure, try> as.Date(730456-367, origin=''0001-01-01'')[1] "1999-12-02" (from which it transpires that the non-existing year 0 is a leap year...). Or, or course, just use the appropriate "magic constant" of 719529 and begone with it:> as.Date(730456-719529)[1] "1999-12-02" I fail to see what "zoo" has to do with this at all! -- Peter Dalgaard Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com

On Mon, Jul 18, 2011 at 8:56 AM, peter dalgaard <pdalgd at gmail.com> wrote:> > On Jul 18, 2011, at 14:08 , Gabor Grothendieck wrote: > >> On Sat, Jul 16, 2011 at 11:50 PM, Eduardo M. A. M. Mendes >> <emammendes at gmail.com> wrote: >>> Hello >>> >>> I am new to R and I need to convert some dates (numeric format by matlab) to actual dates in R. >>> >>> For instance, >>> >>> Matlab -> 730456 -> >> datestr(730456) >>> >>> ans >>> >>> 02-Dec-1999 >>> >> >> Set the origin to Matlab''s origin like this. ?Be sure you are using >> the indicated version of zoo or later: >> >>> library(zoo) >>> packageVersion("zoo") >> [1] ?1.7.1? >>> as.Date(730456, origin = "0000-00-00") >> [1] "1999-12-02" > > Doesn''t work on a Mac, and in general, I think it depends on a quirk in your OS''s date conversion utilities. What does work for me isDid you have zoo 1.7-1 loaded? What happens when you try it?> >> as.Date(730456-1, origin=''0000-01-01'') > [1] "1999-12-02" > > but even this is dubious, since there is no year 0 AD. In Gregorian and Julian calendars, 1 BC continues directly into 1 AD. > > So, to be sure, try > >> as.Date(730456-367, origin=''0001-01-01'') > [1] "1999-12-02" > > (from which it transpires that the non-existing year 0 is a leap year...). > > Or, or course, just use the appropriate "magic constant" of 719529 and begone with it: > >> as.Date(730456-719529) > [1] "1999-12-02" > > > I fail to see what "zoo" has to do with this at all!zoo has its own as.Date.numeric method which accepts a superset of inputs that base::as.Date.numeric accepts. -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com

On Jul 18, 2011, at 15:48 , Gabor Grothendieck wrote:> On Mon, Jul 18, 2011 at 8:56 AM, peter dalgaard <pdalgd at gmail.com> wrote: >> >> On Jul 18, 2011, at 14:08 , Gabor Grothendieck wrote: >> >>> On Sat, Jul 16, 2011 at 11:50 PM, Eduardo M. A. M. Mendes >>> <emammendes at gmail.com> wrote: >>>> Hello >>>> >>>> I am new to R and I need to convert some dates (numeric format by matlab) to actual dates in R. >>>> >>>> For instance, >>>> >>>> Matlab -> 730456 -> >> datestr(730456) >>>> >>>> ans >>>> >>>> 02-Dec-1999 >>>> >>> >>> Set the origin to Matlab''s origin like this. Be sure you are using >>> the indicated version of zoo or later: >>> >>>> library(zoo) >>>> packageVersion("zoo") >>> [1] ?1.7.1? >>>> as.Date(730456, origin = "0000-00-00") >>> [1] "1999-12-02" >> >> Doesn''t work on a Mac, and in general, I think it depends on a quirk in your OS''s date conversion utilities. What does work for me is > > Did you have zoo 1.7-1 loaded? What happens when you try it?I did, actually:> packageVersion("zoo")[1] ?1.7.1?> as.Date(''00-00-0000'')Error in charToDate(x) : character string is not in a standard unambiguous format> as.Date(''0000-00-00'')Error in charToDate(x) : character string is not in a standard unambiguous format> as.Date(1, origin=''0000-00-00'')Error in charToDate(x) : character string is not in a standard unambiguous format> as.Date(730456, origin=''0000-00-00'')Error in charToDate(x) : character string is not in a standard unambiguous format ..... However, this was after reinstalling and reloading zoo. Restarting R and retrying did indeed make things work.>> >> I fail to see what "zoo" has to do with this at all! > > zoo has its own as.Date.numeric method which accepts a superset of > inputs that base::as.Date.numeric accepts.Aha. Thanks. -- Peter Dalgaard Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com

On Mon, Jul 18, 2011 at 10:08 AM, peter dalgaard <pdalgd at gmail.com> wrote:> > On Jul 18, 2011, at 15:48 , Gabor Grothendieck wrote: > >> On Mon, Jul 18, 2011 at 8:56 AM, peter dalgaard <pdalgd at gmail.com> wrote: >>> >>> On Jul 18, 2011, at 14:08 , Gabor Grothendieck wrote: >>> >>>> On Sat, Jul 16, 2011 at 11:50 PM, Eduardo M. A. M. Mendes >>>> <emammendes at gmail.com> wrote: >>>>> Hello >>>>> >>>>> I am new to R and I need to convert some dates (numeric format by matlab) to actual dates in R. >>>>> >>>>> For instance, >>>>> >>>>> Matlab -> 730456 -> >> datestr(730456) >>>>> >>>>> ans >>>>> >>>>> 02-Dec-1999 >>>>> >>>> >>>> Set the origin to Matlab''s origin like this. ?Be sure you are using >>>> the indicated version of zoo or later: >>>> >>>>> library(zoo) >>>>> packageVersion("zoo") >>>> [1] ?1.7.1? >>>>> as.Date(730456, origin = "0000-00-00") >>>> [1] "1999-12-02" >>> >>> Doesn''t work on a Mac, and in general, I think it depends on a quirk in your OS''s date conversion utilities. What does work for me is >> >> Did you have zoo 1.7-1 loaded? ?What happens when you try it? > > > I did, actually: > >> packageVersion("zoo") > [1] ?1.7.1? >> as.Date(''00-00-0000'') > Error in charToDate(x) : > ?character string is not in a standard unambiguous format >> as.Date(''0000-00-00'') > Error in charToDate(x) : > ?character string is not in a standard unambiguous format >> as.Date(1, origin=''0000-00-00'') > Error in charToDate(x) : > ?character string is not in a standard unambiguous format >> as.Date(730456, origin=''0000-00-00'') > Error in charToDate(x) : > ?character string is not in a standard unambiguous format > > ..... > > However, this was after reinstalling and reloading zoo. Restarting R and retrying did indeed make things work. >Does the fact that it worked if R was restarted, but not without, imply that there is something in R that needs to be fixed? -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com

On Jul 18, 2011, at 16:36 , Gabor Grothendieck wrote:>> >> ..... >> >> However, this was after reinstalling and reloading zoo. Restarting R and retrying did indeed make things work. >> > > Does the fact that it worked if R was restarted, but not without, > imply that there is something in R that needs to be fixed?Well, zoo is rewriting code in base. Apparently, it didn''t do it again on the second library(zoo). Not really sure who to blame for what... -- Peter Dalgaard Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com

On Mon, Jul 18, 2011 at 1:59 PM, peter dalgaard <pdalgd at gmail.com> wrote:> > On Jul 18, 2011, at 16:36 , Gabor Grothendieck wrote: >>> >>> ..... >>> >>> However, this was after reinstalling and reloading zoo. Restarting R and retrying did indeed make things work. >>> >> >> Does the fact that it worked if R was restarted, but not without, >> imply that there is something in R that needs to be fixed? > > Well, zoo is rewriting code in base. Apparently, it didn''t do it again on the second library(zoo). Not really sure who to blame for what... >Its done in the .onLoad function in zzz.R in zoo. It seems that if one re-installs zoo and then runs it that the .onLoad is not rerun. I would have thought it would reload the package and therefore .onLoad would be run again.. Also there exists .onAttach but its not used by zoo. Should the code for as.Date.numeric be put in an .onAttach instead or in both .onLoad and .onAttach? -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com

On Jul 18, 2011, at 20:19 , Gabor Grothendieck wrote:> On Mon, Jul 18, 2011 at 1:59 PM, peter dalgaard <pdalgd at gmail.com> wrote: >> >> On Jul 18, 2011, at 16:36 , Gabor Grothendieck wrote: >>>> >>>> ..... >>>> >>>> However, this was after reinstalling and reloading zoo. Restarting R and retrying did indeed make things work. >>>> >>> >>> Does the fact that it worked if R was restarted, but not without, >>> imply that there is something in R that needs to be fixed? >> >> Well, zoo is rewriting code in base. Apparently, it didn''t do it again on the second library(zoo). Not really sure who to blame for what... >> > > Its done in the .onLoad function in zzz.R in zoo. It seems that if > one re-installs zoo and then runs it that the .onLoad is not rerun. I > would have thought it would reload the package and therefore .onLoad > would be run again.. > > Also there exists .onAttach but its not used by zoo. Should the code > for as.Date.numeric be put in an .onAttach instead or in both .onLoad > and .onAttach?Or perhaps not at all! I''ll leave this discussion for others. -- Peter Dalgaard Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com

On Mon, Jul 18, 2011 at 2:57 PM, peter dalgaard <pdalgd at gmail.com> wrote:> > On Jul 18, 2011, at 20:19 , Gabor Grothendieck wrote: > >> On Mon, Jul 18, 2011 at 1:59 PM, peter dalgaard <pdalgd at gmail.com> wrote: >>> >>> On Jul 18, 2011, at 16:36 , Gabor Grothendieck wrote: >>>>> >>>>> ..... >>>>> >>>>> However, this was after reinstalling and reloading zoo. Restarting R and retrying did indeed make things work. >>>>> >>>> >>>> Does the fact that it worked if R was restarted, but not without, >>>> imply that there is something in R that needs to be fixed? >>> >>> Well, zoo is rewriting code in base. Apparently, it didn''t do it again on the second library(zoo). Not really sure who to blame for what... >>> >> >> Its done in the .onLoad function in zzz.R in zoo. ?It seems that if >> one re-installs zoo and then runs it that the .onLoad is not rerun. ?I >> would have thought it would reload the package and therefore .onLoad >> would be run again.. >> >> Also there exists .onAttach but its not used by zoo. ?Should the code >> for as.Date.numeric be put in an .onAttach instead or in both .onLoad >> and .onAttach? > > Or perhaps not at all! > > I''ll leave this discussion for others. >An INSTALL file has been added to zoo to ask users to restart R after installing zoo. -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com

Thanks, I just upgraded to 1.7.1 Also thanks for adding the t() function. On Mon, Jul 18, 2011 at 12:38 PM, Gabor Grothendieck < ggrothendieck@gmail.com> wrote:> On Mon, Jul 18, 2011 at 2:57 PM, peter dalgaard <pdalgd@gmail.com> wrote: > > > > On Jul 18, 2011, at 20:19 , Gabor Grothendieck wrote: > > > >> On Mon, Jul 18, 2011 at 1:59 PM, peter dalgaard <pdalgd@gmail.com> > wrote: > >>> > >>> On Jul 18, 2011, at 16:36 , Gabor Grothendieck wrote: > >>>>> > >>>>> ..... > >>>>> > >>>>> However, this was after reinstalling and reloading zoo. Restarting R > and retrying did indeed make things work. > >>>>> > >>>> > >>>> Does the fact that it worked if R was restarted, but not without, > >>>> imply that there is something in R that needs to be fixed? > >>> > >>> Well, zoo is rewriting code in base. Apparently, it didn''t do it again > on the second library(zoo). Not really sure who to blame for what... > >>> > >> > >> Its done in the .onLoad function in zzz.R in zoo. It seems that if > >> one re-installs zoo and then runs it that the .onLoad is not rerun. I > >> would have thought it would reload the package and therefore .onLoad > >> would be run again.. > >> > >> Also there exists .onAttach but its not used by zoo. Should the code > >> for as.Date.numeric be put in an .onAttach instead or in both .onLoad > >> and .onAttach? > > > > Or perhaps not at all! > > > > I''ll leave this discussion for others. > > > > An INSTALL file has been added to zoo to ask users to restart R after > installing zoo. > > > -- > Statistics & Software Consulting > GKX Group, GKX Associates Inc. > tel: 1-877-GKX-GROUP > email: ggrothendieck at gmail.com > > ______________________________________________ > R-help@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide > http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. >[[alternative HTML version deleted]]

> but even this is dubious, since there is no year 0 AD. In Gregorian > and Julian calendars, 1 BC continues directly into 1 AD.True, but these days we are ruled by ISO 8601:2004, which does define a year 0 (the year before 1CE aka 1AD). See http://en.wikipedia.org/wiki/0_(year) . It seems also to redefine the meaning of ''Gregorian calendar'' calling what you are referring to the ''BC/AD calendar system''. (Those who prefer BCE/CE to BC/AD might note the usage of the latter in the definitive international standard.) On Mon, 18 Jul 2011, peter dalgaard wrote:> > On Jul 18, 2011, at 14:08 , Gabor Grothendieck wrote: > >> On Sat, Jul 16, 2011 at 11:50 PM, Eduardo M. A. M. Mendes >> <emammendes at gmail.com> wrote: >>> Hello >>> >>> I am new to R and I need to convert some dates (numeric format by matlab) to actual dates in R. >>> >>> For instance, >>> >>> Matlab -> 730456 -> >> datestr(730456) >>> >>> ans >>> >>> 02-Dec-1999 >>> >> >> Set the origin to Matlab''s origin like this. Be sure you are using >> the indicated version of zoo or later: >> >>> library(zoo) >>> packageVersion("zoo") >> [1] ?1.7.1? >>> as.Date(730456, origin = "0000-00-00") >> [1] "1999-12-02" > > Doesn''t work on a Mac, and in general, I think it depends on a quirk in your OS''s date conversion utilities. What does work for me is > >> as.Date(730456-1, origin=''0000-01-01'') > [1] "1999-12-02" > > but even this is dubious, since there is no year 0 AD. In Gregorian > and Julian calendars, 1 BC continues directly into 1 AD. > > So, to be sure, try > >> as.Date(730456-367, origin=''0001-01-01'') > [1] "1999-12-02" > > (from which it transpires that the non-existing year 0 is a leap year...). > > Or, or course, just use the appropriate "magic constant" of 719529 and begone with it: > >> as.Date(730456-719529) > [1] "1999-12-02" > > > I fail to see what "zoo" has to do with this at all! > > > -- > Peter Dalgaard > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com > > ______________________________________________ > R-help at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. >-- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595

On Monday, July 18, 2011 05:56:14 peter dalgaard wrote:> but even this is dubious, since there is no year 0 AD. In Gregorian and > Julian calendars, 1 BC continues directly into 1 AD. >Although this seems to be a widely recognized "problem," I would argue it is an entirely specious one. It makes no more sense to recognize a "year 0" than it would worry about the lack of a "zeroth" inch or We name centuries and decades without issues. in smaller time intervals with no problem. The entire concern comes down to naming issue. Whenever a fraction from the first inch on a ruler is named, it is written as 0.* or */** - with either a preceding 0, or as a common fraction written without any preceding whole number. Every year in the 19th century starts with "18" yet few people are confused. Why has this ever been regarded as an issue? JWDougherty

2011/7/19 Prof Brian Ripley <ripley at stats.ox.ac.uk>:>> but even this is dubious, since there is no year 0 AD. In Gregorian >> and Julian calendars, 1 BC continues directly into 1 AD. > > True, but these days we are ruled by ISO 8601:2004, which does define a year > 0 (the year before 1CE aka 1AD). See > http://en.wikipedia.org/wiki/0_(year) . > > It seems also to redefine the meaning of ''Gregorian calendar'' calling what > you are referring to the ''BC/AD calendar system''. ?(Those who prefer BCE/CE > to BC/AD might note the usage of the latter in the definitive international > standard.)The Date class has not been extended to support "0000-00-00"; rather, the origin argument of as.Date.numeric has been extended to allow "0000-00-00". There is no real difference between something like origin = "0000-00-00" and origin = "matlab", say. -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com