Hi All: I've been following this thread and just want to add one pointer. For those who aren't interested in using new packages that try to make dates-times easier but also find the base R tools confusing, below is link to an extremely well written document from over 15 years ago. It's probably already known by quite a few people but, for people with less than 10 years of R experience it could very well be unknown. It's the clearest explanation of base R tools for dates and times ( note: one needs to consider chron a base package but who's counting ) that I know of.
https://www.researchgate.net/publication/229087103_R_Help_Desk_Date_and_time_classes_in_R On Sun, Apr 5, 2020 at 4:58 PM Abby Spurdle <spurdl...@gmail.com> wrote: > I think POSIXct and POSIXlt are badly-chosen names. > The name "POSIX" implies UNIX. > (i.e. XYZix operating system is mostly POSIX compliant... Woo-Hoo!). > My assumption is that most people modelling industrial/econometric > data etc, or data imported from databases, don't want system > references everywhere. > > Historically, I've use the principle that: > If programming language A uses functionality from programming language > B, then bindings should be as close as possible to whatever is in > programming language B. Any additional functionality in programming > language A, should be distinct from the bindings. > R hasn't done this here, where POSIX-bindings have added in additional > R functionality and semantics. > Possibly introducing problems at an early stage. > > The help file entitled DateTimeClasses, only covers a small subset of > information on date and time classes, with no obvious information > about how to construct date and time objects, except for what's in the > examples. The Date class has a similar problem, omitting information > about how to construct Date objects. > > The "convenience extraction functions" aren't necessarily convenient > because they return text rather than integers, requiring many users to > still use the POSIXlt class. > > I don't think your example is simple. > And I suspect it may discourage some people from using base packages. > Having opposite effect to what's intended. > > It's probably too late to change the functions, but here's what I would > suggest: > > (1) Create a top-level help page with a title like "Date and Time > Classes" to give a brief but general overview. This would mean the > existing DateTimeClasses would need a new title. > (2) Create a another function the same as as.POSIXlt, but with a more > user-friendly name, which would increase readability. > (3) If help files for describing classes are separate from the help > files for creating/coercing objects (e.g. Date vs as.Date), then I > think they should cross reference each other in the description field, > not just the details or seealso fields. > (4) Reference relevant extraction/formatting functions, in most > date/time help files, even if there's some (small) duplication in the > help files. > (5) Focus on keeping the examples simple rather than comprehensive. > > Expanding on suggestion (4), if you read the help file for as.Date > (which seems like an obvious starting point, because that's where I > started reading...), there's no reference at all to getting the month, > or the day of the week, etc. To make it worse it doesn't mention > coercion to POSIXlt objects either (but does mention coercion from > POSIXlt to Date objects). This could give the wrong impression to many > readers... > > In it's defense, it does link to Date, which links to weekdays, which > links to as.POSIXlt. > > Of course the note and seealso fields are near the bottom, and there's > an implicit (possibly false) assumption that the reader will read all > the help file*s*, and follow the links at the bottom, at least three > times over. > And a new-ish R user is likely to have to read more than four help files. > Unless they Google it, read stack exchange, or read some fancy > (apparently modern) textbook on data science... > > Reinforcing the need for the help files to be clear about what the > functions (collectively) can do and specifically what > extraction/formatting functionality is available... > > My guess is the that most common tasks with date and time objects are: > (1) Reading a character vector representing dates/times. > (2) Formatting a date/time (i.e. Object to character vector, or > character vector to another character vector). > (3) Extracting information such as month, weekday, etc, either as an > integer or as text. > > So, I in short, these should be easy (to do, and find out how to do)... > > > On Sat, Apr 4, 2020 at 10:51 PM Martin Maechler > <maech...@stat.math.ethz.ch> wrote: > > > > This is mostly a RFC [but *not* about the many extra packages, > please..]: > > > > Noticing to my chagrin how my students work in a project, > > googling for R code and cut'n'pasting stuff together, accumulating > > this and that package on the way all just for simple daily time series > > (though with partly missing parts), > > using chron, zoo, lubridate, ... all for things that are very > > easy in base R *IF* you read help pages and start thinking on > > your own (...), I've noted once more that the above "if" is a > > very strong one, and seems to happen rarely nowadays by typical R > users... > > (yes, I stop whining for now). > > > > In this case, I propose to slightly improve the situation ... > > by adding a few more lines to one help page [[how could that > > help in the age where "google"+"cut'n'paste" has replaced thinking ? .. > ]] : > > > > On R's own ?Dates help page (and also on ?DateTimeClasses ) > > we have pointers, notably > > > > See Also: > > > > ............... > > ............... > > > > 'weekdays' for convenience extraction functions. > > > > So people must find that and follow the pointer > > (instead of installing one of the dozen helper packages). > > > > Then on that page, one sees weekdays(), months() .. julian() > > in the usage ... which don't seem directly helpful for a person > > who needs more. If that person is diligent and patient (as good useRs > are ;-), > > she finds > > > > Note: > > > > Other components such as the day of the month or the year are > very > > easy to compute: just use 'as.POSIXlt' and extract the relevant > > component. Alternatively (especially if the components are > > desired as character strings), use 'strftime'. > > > > > > But then, nowadays, the POSIXlt class is not so transparent to the > > non-expert anymore (as it behaves very much like POSIXct, and > > not like a list for good reasons) .. and so 97% of R users will > > not find this "very easy". > > > > For this reason, I propose to at add the following to the > > 'Examples:' section of the help file ... > > and I hope that also readers of R-devel who have not been > > aware of how to do this nicely, will now remember (or remember > > where to look?). > > > > I at least will tell my students in the future to use these or > > write versions of these simple utility functions. > > > > > > ------------------------------------------------ > > > > ## Show how easily you get month, day, year, day (of {month, week, yr}), > ... : > > ## (remember to count from 0 (!): mon = 0..11, wday = 0..6, etc !!) > > > > ##' Transform (Time-)Date vector to convenient data frame : > > dt2df <- function(dt, dName = deparse(substitute(dt)), stringsAsFactors > = FALSE) { > > DF <- as.data.frame(unclass(as.POSIXlt( dt )), > stringsAsFactors=stringsAsFactors) > > `names<-`(cbind(dt, DF, deparse.level=0L), c(dName, names(DF))) > > } > > dt2df(.leap.seconds) # date+time > > dt2df(Sys.Date() + 0:9) # date > > > > ##' Even simpler: Date -> Matrix: > > d2mat <- function(x) simplify2array(unclass(as.POSIXlt(x))) > > d2mat(seq(as.Date("2000-02-02"), by=1, length.out=30)) # has R 1.0.0's > release date > > > > ------------------------------------------------------------ > > > > In the distant past / one of the last times I touched on people > > using (base) R's Date / Time-Date objects, I had started > > thinking if we should not provide some simple utilities to "base R" > > (not in the 'base' pkg, but rather 'utils') for "extracting" from > > {POSIX(ct), Date} objects ... and we may have discussed that > > within R Core 20 years ago, and had always thought that this > > shouldn't be hard for useRs themselves to see how to do... > > > > But then I see that "everybody" uses extension packages instead, > > even in the many situations where there's no gain doing so, > > but rather increases the dependency-complexity of the data analysis > > unnecessarily. > > > > Martin Maechler > > ETH Zurich and R Core Team. > > > > ______________________________________________ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
