Re: unix time in plot (an Octave problem?)

[Mike Miller]

On Mon, Jul 20, 2015 at 15:39:07 -0400, Vic Norton wrote:
> I put the unix times above in the following Octave script:
>  printf("This looks right. It's what I want.\n");
>  printf("  %s\n", strftime("%Y-%m-%d %X %Z", gmtime(1420027200)));
>  printf("  %s\n", strftime("%Y-%m-%d %X %Z", gmtime(1435665600)));
>  printf("  %s\n", strftime("%Y-%m-%d %X %Z", gmtime(1451563200)));
>  printf("But shouldn't all the %%z time zones read +0000?\n");
>  printf("  %s\n", strftime("%Y-%m-%d %X %z", gmtime(1420027200)));
>  printf("  %s\n", strftime("%Y-%m-%d %X %z", gmtime(1435665600)));
>  printf("  %s\n", strftime("%Y-%m-%d %X %z", gmtime(1451563200)));
> The results are a bit disturbing:
>  This looks right. It's what I want.
>    2014-12-31 12:00:00 UTC
>    2015-06-30 12:00:00 UTC
>    2015-12-31 12:00:00 UTC
>  But shouldn't all the %z time zones read +0000?
>    2014-12-31 12:00:00 -48038628
>    2015-06-30 12:00:00 -48040837
>    2015-12-31 12:00:00 -48053659
> See, for example,
> http://search.cpan.org/~dexter/POSIX-strftime-GNU-0.0301/lib/POSIX/strftime/GNU.pm

I agree, I get the same output.

Two things:

 1. Note that "%z" is not documented in "help strftime", although I
 agree it is reasonable to expect it to work if you're familiar with the
 standard C function of the same name.

 2. We use the gnulib implementation of strftime, which I think is where
 the bug lies. If you're willing, you could work up a minimal example to
 verify that the bug lies in gnulib, report it to the gnulib project,
 and we can absorb the fix in Octave.

If not, at least report a bug on the Octave bug tracker.

Thanks for the demonstration,

-- 
mike