as.Date.timeDate

Achim Zeileis Achim.Zeileis at uibk.ac.at
Tue Oct 18 18:36:17 CEST 2011


Martin,

thanks for the feedback. Yes, the approach is bad, but so is the approach 
of the 'origin' argument without default in base::as.Date.numeric. And, 
yes, this is all a big kludge.

However, my feeling is that we could avoid some additional confusion by 
simply fully exporting all as.Date.* functions (just like base R does). 
This also reduces the overhead that the individual packages with 
generics/methods have to provide.

The devel-version of zoo on R-Forge now does this and hence we asked 
whether timeDate could do the same.

If there is another way of resolving this problem without further adding 
dependencies to zoo (or any other package involved), I would also be 
interested.

Thanks & best regards,
Achim


On Tue, 18 Oct 2011, Martin Maechler wrote:

>>>>>> Gabor Grothendieck <ggrothendieck at gmail.com>
>>>>>>     on Tue, 18 Oct 2011 10:03:11 -0400 writes:
>
>    > While the change is caused by the second generic in zoo
>    > (which was necessitated by a change in R), note that the
>    > de facto standard set by the base package is to export all
>    > as.Date methods.
>
> that's not a "standard" but rather a kludge or
> a "historical coincidence" / an accidental reference to the past
> or ....
> as far as I see it...
>
> Really this should be discussed on R-devel, Gabor.
>
>    >   As we see, none of these methods are asterisked:
>
>    >> methods(as.Date)
>    > [1] as.Date.character as.Date.date      as.Date.dates     as.Date.default
>    > [5] as.Date.factor    as.Date.numeric   as.Date.POSIXct   as.Date.POSIXlt
>
>    > If timeDate follows the same standard then there will be no problem.
>
> Well, that's rather a *NON*-standard.
> The only reason I can think of currently that
> "base R" does not properly hide these is because they were
> already (mis)used in other CRAN packages.
>
> But I don't see why timeDate should have to do the same thing
> which is "wrong" and recommended against typically in several
> places ("Writing R Extensions").
>
> Of course, if there's no better solution, that's still a
> possibility, but this whole approach  "smells a bit bad" to me.
>
> Martin
>
>    > On Tue, Oct 18, 2011 at 8:58 AM, Yohan Chalabi <chalabi at phys.ethz.ch> wrote:
>    >> Hi Gabor,
>    >>
>    >> Thanks for the message.
>    >>
>    >> As mentioned in the r-sig-finance, timeDate already exports as.Date.timeDate.
>    >>
>    >> The problem is really coming from zoo which overwrites the base function as.Date and do not import as.Date methods from other packages.
>
> I still think
>
>    >>
>    >> Regards,
>    >> Yohan
>    >>
>    >> On 14 oct. 2011, at 20:37, Gabor Grothendieck wrote:
>    >>
>    >>> Changes in R have necessitated a change in zoo which results in any
>    >>> as.Date method in the timeDate package (or any other package that does
>    >>> not export their as.Date methods) not to be dispatched.
>    >>>
>    >>> This can be fixed by either exporting any as.Date method in the
>    >>> NAMESPACE file (or by importing zoo in the NAMESPACE file).
>    >>>
>    >>> See:
>    >>>
>    >>> https://stat.ethz.ch/pipermail/r-sig-finance/2011q4/008751.html
>    >>>
>    >>> --
>    >>> Statistics & Software Consulting
>    >>> GKX Group, GKX Associates Inc.
>    >>> tel: 1-877-GKX-GROUP
>    >>> email: ggrothendieck at gmail.com
>    >>>
>    >>> _______________________________________________
>    >>> Rmetrics-core mailing list
>    >>> Rmetrics-core at r-project.org
>    >>> https://stat.ethz.ch/mailman/listinfo/rmetrics-core
>    >>>
>    >>
>    >>
>
>
>
>    > --
>    > Statistics & Software Consulting
>    > GKX Group, GKX Associates Inc.
>    > tel: 1-877-GKX-GROUP
>    > email: ggrothendieck at gmail.com
>
>    > _______________________________________________
>    > Rmetrics-core mailing list
>    > Rmetrics-core at r-project.org
>    > https://stat.ethz.ch/mailman/listinfo/rmetrics-core
>
> _______________________________________________
> Rmetrics-core mailing list
> Rmetrics-core at r-project.org
> https://stat.ethz.ch/mailman/listinfo/rmetrics-core
>



More information about the Rmetrics-core mailing list