Skip to content

Timezone warnings on package install in R-alpha

8 messages · Dirk Eddelbuettel, Brian Ripley, Jon Clayden +2 more

#
I'm seeing nothing of the sort with the nightly build of 3.1.0RC, also on 10.9.2. This is a plain-vanilla Xcode+ancillaries build as per Simon's instructions (I think):

pd$ more config.site 
r_arch=${r_arch:=x86_64}
CC="gcc -arch $r_arch"
CXX="g++ -arch $r_arch"
F77="gfortran -arch $r_arch"
FC="gfortran -arch $r_arch"
OBJC="gcc -arch $r_arch"
with_blas="-framework vecLib"
with_lapack=yes

so either something is up specifically with gcc-4.8, or you managed to hose your time zone data base somehow (/usr/share/zoneinfo, I suppose).

- Peter D.
On 03 Apr 2014, at 13:24 , Jon Clayden <jon.clayden at gmail.com> wrote:

            

  
    
#
On 3 April 2014 at 12:24, Jon Clayden wrote:
| For what it's worth, this issue persists in R-rc_2014-04-02_r65358.

I'm running a beta version on Ubuntu and do not see this, neither on INSTALL
or check during package development nor during normal use:

R> R.version
               _                                       
platform       x86_64-pc-linux-gnu                     
arch           x86_64                                  
os             linux-gnu                               
system         x86_64, linux-gnu                       
status         beta                                    
major          3                                       
minor          1.0                                     
year           2014                                    
month          03                                      
day            28                                      
svn rev        65330                                   
language       R                                       
version.string R version 3.1.0 beta (2014-03-28 r65330)
nickname       Spring Dance                            
R> format(Sys.time())
[1] "2014-04-03 07:30:17.171488"
R> format(Sys.time(), tz="America/New_York")
[1] "2014-04-03 08:30:28.771662"
R> format(Sys.time(), tz="Europe/Berlin")
[1] "2014-04-03 14:30:41.211835"
R> Sys.getenv("TZ")
[1] ""
R> 

As you can see, I do not set a TZ variable and things work here.

Dirk
#
On 03/04/2014 13:27, peter dalgaard wrote:
More likely the one shipping with R, since --with-internal-tzcode is the 
default on OS X [*].  Setting TZDIR incorrectly would do this:

 > Sys.time()
[1] "2014-04-03 12:37:01 GMT"
Warning messages:
1: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'Europe/London'
2: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
3: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'America/New_York'

when I do that.

You could try --without-internal-tzcode.

[*] Although x86_64 OS X has a 64-bit time_t it seems to have a 32-bit 
time-zone database and so wraps around.

  
    
#
Thanks to Brian. Yet another thing that zoomed by without me really noticing.

However, I'd like to be sure that it isn't a "make dist" issue. We do seem to ship the correct files in src/extra/tzone, but could you please check Brian's suggestion about TZDIR possibly being set incorrectly?

-pd
On 03 Apr 2014, at 14:47 , Jon Clayden <jon.clayden at gmail.com> wrote:

            

  
    
2 days later
#
Hi,

I just discovered a small issue that fits into this thread.

Consider:
z <- as.POSIXlt(Sys.time())
z$gmtoff

Under both Fedora and Windows (using R 3.1.0) I get the
value -14400, which is the number of SECONDS offset
from GMT (for New York), not the number of minutes
offset as specified in the man page for POSIXlt.

I assume that gmtoff is the offset that results when
the adjustment due to z$isdst has already been applied,
so it changes with the seasons, unlike the fixed geographic
zone (-5 for New York City). Please correct me if I am wrong.

Finally, I seem to recall that I was able to read a zoneinfo
file to fetch information like longitude and latitude for the
city that is returned by Sys.timezone(), but either I forgot
how to do this, or the procedure no longer applies. Is this
kind of thing supported?

Thanks,
Dominick
On Thu, Apr 3, 2014 at 10:08 AM, Jon Clayden <jon.clayden at gmail.com> wrote: