Re: Octave date and time services

[Mike Miller]

On Sat, May 12, 2018 at 17:15:23 +0100, Ian McCallion wrote:
> I think I can best serve
> Octave by writing up the bug reports you would like written up and the
> next step should be for you to say which they are.

Ok, sounds good.

> Yes. I'm in the UK and on Windows (4.2.2 and 4.4.0):
> >> localtime(time)
>     usec =  178342
>     sec =  59
>     min =  32
>     hour =  8
>     mday =  12
>     mon =  4
>     year =  118
>     wday =  6
>     yday =  131
>     isdst =  1
>     gmtoff = 0
>     zone = GMT Daylight Time

Ok, on Windows, the gmtoff and zone fields are not implemented. The
gmtoff field will always be zero, and Octave will call tzname to
populate the zone field. This may not be the ideal way to represent that
these fields are optional and may not be valid on a particular system.

This could be documented in the Octave user manual.

We could also include documentation that these fields are extensions and
are informational only, they are not used by the mktime function.

> No. On 4.2.2 and 4.4.0 on Windows, after running this I get t1==t2==t3=
>     usec =  140346
>     sec =  41
>     min =  35
>     hour =  8
>     mday =  12
>     mon =  4
>     year =  118
>     wday =  6
>     yday =  131
>     isdst =  1
>     gmtoff = 0
>     zone = GMT Daylight Time
> 
> > If not, that may be a defect in your operating system, it works for me.
> 
> Assuming you meant "a defect in the Octave build for Windows" rather
> than "a defect in Windows", it would seem highly likely.

The POSIX function tzset serves the purpose of copying the TZ
environment variable into the runtime for other time functions to use.

According to the GNU libc documentation,

| It is not usually necessary for your program to call this function,
| because it is called automatically when you use the other time
| conversion functions that depend on the time zone.

It appears that the localtime function on GNU/Linux operating systems
automatically calls tzset to update the internal time zone information
from the TZ environment variable. On Windows, it seems to be that the
localtime function does not, but the mktime function does. That's what I
meant by defect in your operating system.

I think this would be appropriate to fix in Octave, by explicitly
calling tzset wherever it may be needed.

> > I don't think it's within the scope of the Octave documentation to
> > describe the TZ environment variable. I think it would be appropriate to
> > refer to the section in the GNU libc manual.
> 
> That's one philosophy. I believe though that many Octave users are
> scientists with no interest in programming. So a little more help may be
> appropriate when they need to use functions that give access to operating
> system services, and especially operating system services for an
> operating system and programming langage they are not running and
> cannot get support on. And I note that your philosophy was not applied
> in section "14.2 C-style I/O functions", which documents printf etc
> without reference to C manuals.

I think it's fair to file a bug report to document, at the very least,
the existence of the TZ environment variable. How much depth that
documentation will go into can be discussed.

> There is also the question of what setting TZ affects. For Octave on
> windows (which has no concept of process-local timezone, so no
> TZ or similar environment variable) it just affects the behaviour of
> octave timing functions. For Octave on Unix it (I assume) changes
> the effective timezone for system services also.

I'm not sure I follow here. I think GNU and Windows and Unix operating
systems all support a TZ environment variable and a concept of
per-process time zone. Setting the TZ environment variable in Octave
never has an effect on the system time zone setting.

> So date-time arithmetic in general (not just datenum) does not reference
> a table of leap seconds, and as a corollary, Octave seconds(*) are on
> average bigger than TAI seconds,
> https://www.timeanddate.com/time/international-atomic-time.html, to
> compensate. I think it is worth saying.

Correct.

> (*) Yes of course Octave seconds are System seconds, and virtually all
> systems will take their time from a public NTP service which will have a
> strategy for dealing with the problem, e.g.
> https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-
> count-with-our-new-public-NTP-servers.html.

Right.

Cheers,

-- 
mike

signature.asc
Description: PGP signature