From spluque at gmail.com  Fri Jul 14 23:39:00 2006
From: spluque at gmail.com (Sebastian Luque)
Date: Fri, 14 Jul 2006 16:39:00 -0500
Subject: [Rd] chron vs. POSIX
References: <87psg8rn75.fsf@arctocephalus.homelinux.org>
	<17591.64287.118524.251828@basebud.nulle.part>
Message-ID: <87y7uvuarv.fsf@arctocephalus.homelinux.org>

[Sorry for my previous empty post]

Dirk Eddelbuettel <edd at debian.org> wrote:

> On 14 July 2006 at 14:38, Sebastian Luque wrote:
> | If Gabor's recommendations are to be followed, wouldn't it make sense
> | to include chron in base R?  Given that flexibility for handling time

> Future historians will provide a fuller account of the extended debates,
> but my reading of these discussions here over the last few years leaves
> me with the impression that Gabor is arguing for chron in a manner that
> is simultaneously informed, polite, persistent and yet ... utterly
> isolated.

> Date and POSIXt have served me well over the last few years. They are
> maintained and being extended [ 1 ]. Chron, to the best of my knowledge,
> is dead code so I'd bet against it appearing in core R any time soon.

That is not true, as Gabor pointed out.  At any rate, I can't understand
why there's only a choice between a dates-only class and another one
including every detail of time in R base.  As mentioned in Gabor's R News
article, the latter requires the user to pay attention to time zones and
daylight savings details that are completely irrelevant in some cases.
The drawbacks of using POSIX classes, in cases where TZ and DS are
irrelevant, can be quite serious when writing relatively complex code?.


[...]


Cheers,

+---- *Footnotes* ----+
? In addition to the list in the R News article, there's also issues with
  TZ attribute being lost after operations such as 'sapply' with POSIX
  objects.  Spotting that problem, and how to recover your POSIX object
  after that is not as simple as doing chron('sapply return value').

-- 
Seb



[Rd] chron vs. POSIX
Sebastian Luque