kajsamp
commented
6 years ago I have included PCICt as a suggested package in esd, meaning that it is not required but can be used in some functions. It is included in the DESCRIPTION under Suggested. This can be a good strategy when you wish to use an external package without adding new dependencies.
Before applying a function (e.g., as.PCICt) from a suggested package, you need to check that it is installed (using 'requireNamespace') and then if it isn't, either redirect to a fallback method or give an error message. The package should not be imported but instead explicitly referred to with the syntax package::function() (e.g., PCICt::as.PCICt() ). This also makes it is easy to see that the function is part of an external package.
abdelkaderm
I am updating retrieve to deal better with daily and sub-daily data. It's working fine except when reading data from climate models that have a 360-day calendar. The built in date-time types of R and zoo can't handle the 360-day calendar (30 days in every month) and this leads to problems with, e.g., February 30. I have come up with two possible solutions: 1) Avoid using daily/subdaily data from climate models that have 360-days and add a warning saying that esd can't handle these data types, in case someone tries to use it. Most climate models have switched to a 365-day or Gregorian calendar anyways. 2) Use the R package PCICt to handle the daily/subdaily data with 360-day calendars. This is an implementation of POSIXct Work-Alike for 365 and 360 Day Calendars. The drawback is that we would be adding another dependency to the esd package.