This is probably a very basic question but since I did not deal with dates and times in R, I didn't know how to solve it. The problem is when I open a new R session and run sys.time() it gives me wrong time. I found a solution to that Sys.setenv(TZ="TURKEY") and changed it. However, when I close R and open it again. It goes back to wrong result again. How do I make this permanent?
> Sys.time()
[1] "2022-04-01 11:16:37 GMT"
Warning messages:
1: In normalizePath(dirname(f)) : path[1]="NA": No such file or directory
2: In as.POSIXlt.POSIXct(x, tz) :
unknown timezone 'zone/tz/2022a.1.0/zoneinfo/Europe/Istanbul'
> Sys.setenv(TZ="TURKEY")
> Sys.time()
[1] "2022-04-01 14:17:39 EEST"
You can set TZ="TURKEY" in your .Renvironment file. This will load each time you (re)start R, and thus you will always get the timezone you want.
.Renvironment files can be created for each R project, or globally for all your projects. You can see this answer for how to create a global .Renvironment file .
Related
I am trying to load an .RData file downloaded from the github repository https://github.com/VCCRI/SPAGI/tree/master/data.
After having saved the files on my computer if I try to load one of them with
load("./data/pathwaypath.RData")
I get the error message:
Warning message:
“file ‘pathwaypath.RData’ has magic number ''
Use of save versions prior to 2 is deprecated”
Error in load("./data/pathwaypath.RData"): bad restore file magic number (file may be corrupted) -- no data loaded
Traceback:
1. load("./data/pathwaypath.RData")
It also does not work with readRDS:
readRDS("./data/pathwaypath.RData")
throws
Error in readRDS("./data/pathwaypath.RData"): unknown input format
Traceback:
1. readRDS("./data/pathwaypath.RData")
Browsing through stackoverflow I gained the sense that it might be a problem with the serialization protocol used for creating the .RData object. Would anyone know more about it? Are there any known solutions to this issue?
I am running R version 4.0.0 (2020-04-24).
Here's an approach that is working for me on version 3.6.3:
temp <- tempfile()
download.file("https://github.com/VCCRI/SPAGI/blob/master/data/pathway.path.RData?raw=true",temp)
load(temp)
pathway.path[[1]][1:3]
#[[1]]
#[1] "RTN4R" "NGFR" "IRAK1" "MAP3K7" "IKBKB" "NFKB1"
#
#[[2]]
#[1] "RTN4R" "NGFR" "IRAK1" "MAP3K7" "IKBKB" "FOXO3"
#
#[[3]]
#[1] "RTN4R" "NGFR" "MAPK8" "JUN"
I am trying to convert a unix epoch timestamps to a date-time object using as.POSIXct()
I need to specify timezones (either Europe/London or UTC) when I call as.POSIXct().
If I run
> t<-as.POSIXct(1445329330, tz="Europe/London", origin="1970-01-01")
> t
R returns
"2015-10-20 09:22:10 BST"
Warning messages:
1: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'default/Europe/London'
2: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'default/Europe/London'
I have tried specifying tz="BST", but this also returns warnings
Warning messages:
1: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'BST
'
2: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'default/Europe/London'
3: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'BST
'
4: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'default/Europe/London'
I have looked up the zoneinfo/zone.tab as per Joshua Ulrich's post and "Europe/London" does appear in the zone.tab file, while "BST" does not. So I think that Europe/London should be a valid tz option. Is this correct?
Does anyone have suggestions as to why I am getting warnings, and why the specified timezone is not being assigned to the as.POSIXct object?
It should be noted that my scripts which call as.POSIXct() were running without warnings prior to updating MacOS to High Sierra. Could the OS update lead to these warnings? When I run Sys.timezone() it returns NA
Many thanks in advance
Iris
I am having a similar issue on macOS High Sierra 10.13.1. As soon as, I try to do anything with dates, I get the following error.
> as.POSIXct("2017-10-01", format = "%Y-%m-%d")
[1] "2017-10-01 GMT"
Warning message:
In strptime(x, format, tz = tz) :
unknown timezone 'zone/tz/2017c.1.0/zoneinfo/Pacific/Auckland'
The warning goes away if I set the environment variable to my timezone and I get the date back with the correct timezone.
> Sys.setenv(TZ = "Pacific/Auckland")
> as.POSIXct("2017-10-01")
[1] "2017-10-01 NZDT"
So, I have been setting the environment variable every time I need to do something to do with dates.
However, I have found this link talking about the same thing. Peter Dalgaard from R Core Team has replied saying this was a bug in macOS 10.13 Beta and that it is up to Apple to sort it out.
I am thinking to put Sys.setenv(TZ = "Pacific/Auckland") into .Rprofile so that it sets the time zone every time I start RStudio. I hope this helps.
Here is a link that might be useful if you want to try the .Rprofile approach I mentioned.
Update: It seems like this has been resolved in R 3.4.3. You can read more about it in the R news. Below is the related part of the release notes.
INSTALLATION on a UNIX-ALIKE
A workaround has been added for the changes in location of time-zone files in macOS 10.13 'High Sierra' and again in 10.13.1, so the default time zone is deduced correctly from the system setting when R is configured with --with-internal-tzcode (the default on macOS).
I can confirm that the new version of R resolves the issues with date/time objects.
> Sys.timezone()
[1] "Pacific/Auckland"
> Sys.time()
[1] "2017-12-30 16:22:32 NZDT"
It does look like you need to update your system with a timezone, even though it isn't being used.
I can't seem to set my timezone to NA, but if I set my environment with, for example Sys.setenv(TZ='Twilight Zone'), or anything that isn't on the tz list I also get the same errors that you do.
Looking at the output it is not actually giving a warning about 'Europe/London', just about other variations ('BST' and 'default/Europe/London').
Could it be that it are errors of previous commands still lingering? Do you get the same if run you the as.POSIXct(1445329330, tz="Europe/London", origin="1970-01-01") again, or even restart R?
I still get the error about BST even if using the correct timezone
> as.POSIXct(1445329330, tz="BST", origin="1970-01-01")
[1] "2015-10-20 08:22:10 GMT"
Warning message:
In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'BST'
> as.POSIXct(1445329330, tz="Europe/London", origin="1970-01-01")
[1] "2015-10-20 09:22:10 BST"
Warning message:
In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'BST'
I'm using the library ncdf with R version 3.0.2. I'm trying to open and close some netcdfs over and over again (I can explain why but it isn't needed for this question).
sapply(1:14000, function(whatever) {
print(whatever)
sapply(prediction.cdfs, function(cdf) {
print(file.path(cdf.dir, cdf))
nc = open.ncdf(file.path(cdf.dir, cdf))
close.ncdf(nc)
})
})
After open and closing over and over again it eventually fails with this error:
[1] 3329
[1] "/opt/devel/cdfs/file_one.cdf"
[1] "/opt/devel/cdfs/file_two.cdf"
[1] "/opt/devel/cdfs/file_three.cdf"
[1] "/opt/devel/cdfs/file_four.cdf"
[1] "/opt/devel/cdfs/file_five.cdf"
Error in open.ncdf(file.path(cdf.dir, cdf)) :
NAs in foreign function call (arg 1)
Anyone know what's going on? The error seems stochastic in nature. The time till it barks about the foreign function call is variable. I'm looking for an explanation or just a work around?
Thanks
I believe the problem was from un-closed connections to the same files from a previous step in my analysis. I'm running this on a Linux system, so I tracked the open file connections as the loop was running using
watch ls -l /proc/${PID}/fd
The connections opened and closed just fine, but I saw some old connections laying around from my previous analysis. I closed them and everything run just fine!!!
As in What could cause a "bad magic number" error when loading an R workspace and how to avoid it? and R has magic number 'ëPNG' error, I'm getting a bad restore file magic number error:
> load("fossilien.dat")
Error: bad restore file magic number (file may be corrupted) -- no data loaded
In addition: Warning message:
file ‘fossilien.dat’ has magic number '"Samp'
Use of save versions prior to 2 is deprecated
Using the source function gives me a different error (similar to unexpected string constant):
> source("fossilien.dat")
Error in source("fossilien.dat") :
fossilien.dat:1:10: unexpected string constant
1: "Sample" "Sname"
^
This is especially frustrating as I'm confident the source of data is legit - its for a homework problem: ftp://stat.ethz.ch/Teaching/Datasets/WBL/fossilien.dat
None of the SO questions above were really answered properly so I thought I would try again.
Some details about my R installation:
> R.Version()
$platform
[1] "x86_64-apple-darwin9.8.0"
$version.string
[1] "R version 2.15.3 (2013-03-01)"
The read.table function ended up working: http://stat.ethz.ch/R-manual/R-devel/library/utils/html/read.table.html
> fossildata <- read.table("fossilien.dat")
EDIT by CGW: load is for files in .rdata format, while your fossilien.dat clearly is an ASCII table. source executes the named file or object.
If I edit a function with R v2.14.0 using fix(), those fixes are applied during the session.
For example, I might make the following edit to get a white background in a hive plot:
> library(HiveR)
> fix(plotHive)
... :%s/black/white/g
... :w
... :q
> plotHive(myHiveData)
I then get a white background in the hive plot, as expected.
But if I quit and reopen R, I have lost those changes, and the plot has a black background again.
How do I preserve the edits I make with fix() between R sessions?
EDIT
If I source() the modified plotHive() function, I get the following error:
> modifiedPlotHive <- source("modifiedPlotHive.R")
Error in source("modifiedPlotHive.R") :
modifiedPlotHive.R:1160:1: unexpected '<'
1159: }
1160: <
^
In addition: Warning message:
In readLines(file) : incomplete final line found on 'modifiedPlotHive.R'
The final line in the modified plotHive() function is:
<environment: namespace:HiveR>
If I remove this line before source()-ing, then the function no longer works.
Sorry I missed this when it came out, but the latest version of HiveR has the option to control the background color (available on CRAN 0.2-1) Bryan
Here's the safer way of doing what you want, referenced by #joran.
The sink/source pair is fine for dealing with R code files. But saving to text files and then reading back in other types of objects can strip them of important attributes, especially those relating to environments. That's what you just experienced.
The save/load pair stores objects in R's own binary format, so is much less liable to lose important information/environments attached to functions.
In this example, I define a personal version of ls, which differs from the base function in that it by default lists objects that start with a dot/period:
my_ls <- ls
fix(my_ls)
# 1) On the first line, change 'all.names=FALSE' to 'all.names=TRUE'
# 2) Say "Yes", I want to save the changes
save("my_ls", file="my_ls.Rdata")
# Then, in a later session, test that it works
load("my_ls.Rdata")
.TrysToHide <- 99
my_ls()
# [1] ".TrysToHide" "my_ls"
One more note: it's much cleaner to give your modified function a name of its own. To really edit a packaged function, and have the changes persist, you'd need to edit the sources and recompile the package. But if you do that, beware, as you may well break the function for other packaged functions that depend on it.
There are a couple of options:
Save your workspace before quiting and load it again when you reopen R.
Save the modified function to script file and source it:
sink("modified_plotHive.r")
plotHive
sink()
In the next session:
plotHive <- source("modified_plotHive.r")
HTH