[Rd] Re: [R-SIG-Mac] Formatting of time zone for POSIXct

From: Simon Urbanek <simon.urbanek_at_math.uni-augsburg.de>
Date: Thu 20 Jan 2005 - 08:54:13 EST

Don,

thanks for your report.

On Jan 19, 2005, at 12:41 PM, Don MacQueen wrote:

> I'm encountering a problem formatting POSIXct objects in R 2.0.1 on OS
> X.
>
> For reference, on a Solaris system, R 2.0.1 (2004-11-15), formatting
> is correct:
>
>> Sys.time()
> [1] "2005-01-19 09:12:33 PST"
>> format(Sys.time(),'%H:%M %Z')
> [1] "09:12 PST"
>
>
> On Mac OS X, however,
>
> R 2.0.1 Patched 2005-01-19
>
>> Sys.time()
> [1] "2005-01-19 09:18:27 PST"
>> format(Sys.time(),'%H:%M %Z')
> [1] "09:18 P"

The man pages says:

    usetz: logical. Should the timezone be appended to the output? This

           is used in printing time, and as a workaround for problems
           with using '"%Z"' on most Linux systems.

so after reading that, you get the correct result:

 > format(Sys.time(),'%H:%M',usetz=TRUE) [1] "15:57 EST" Now, the reason why I'm CCing this to R-devel is that in fact the datetime.c is somewhat weird for non-GlibC2 systems as tm.tm_zone is not initialized at all, which I suspect is a bug. Either the docs should state that %Z should not be used at all or I'd propose the following patch to make it work (warning, it's a patch against R-devel):

Index: src/main/datetime.c


This just zeroes out tm before use - it should also fix the problems on Linux. Just in case I overlooked something and it's not feasible to zero out the struct tm (e.g. if the size may be unknown), then the following, more paranoid patch could be used:

Index: src/main/datetime.c


      /* coerce fields to integer, find length of longest one */
      for(i = 0; i < 9; i++) {

Index: configure.ac
+dnl some Solaris systems don't have a tm_zone member in struct tm.
+AC_CHECK_MEMBERS([struct tm.tm_zone],,,[
+#if defined(HAVE_TIME_H)
+#include <time.h>
+#endif
+])
+

  ## R profiling.
  if test "${want_R_profiling}" = yes; then     AC_CHECK_FUNCS(setitimer,

The configure patch makes sure we know that struct tm.tm_zone exists and the other patch makes sure it's reset before calling strftime. Any variation hereof would help, too ;)

> Changing the TZ environment variable, from the default of "" to
> "US/Pacific" does not help.

Doing so has no effect for you, because the time zone is correct as you demonstrated yourself in the above output.

Cheers,
Simon



R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Thu Jan 20 07:59:27 2005

This archive was generated by hypermail 2.1.8 : Fri 18 Mar 2005 - 09:02:37 EST