Re: Octave date and time services

[Ian McCallion]

Hi Mike,

Thanks for your reply. I have embedded answers to your questions below
and expanded a couple of my arguments. I don't want to get into a long
discussion, as I'm sure you don't either so 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.

Cheers... Ian
----------------
On 11 May 2018 at 19:17, Mike Miller <address@hidden> wrote:
> On Fri, May 11, 2018 at 11:57:14 +0200, Ian McCallion wrote:
>> <snip>
> Maybe I can reply briefly to each one
> and we can move this to octave-maintainers or to individual bug reports?

Yes. Happy with that and I have subscribed to octave-maintainers.

>> 2. Bug. In the tm_struct returned by the localtime function, the
>> gmtoff field does not appear to be set correctly.
>
> Works for me. Can you give an example?

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

>> merely setting TZ is not sufficient - localtime and maybe other functions
>> seem to reference a cache that is only loaded by mktime.

> Does the following not work for you?
>     x = time ();
>     t1 = localtime (x)
>     setenv TZ UTC0
>     t2 = localtime (x)
>     setenv TZ CST6CDT
>     t3 = localtime (x)

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.

> 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.

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.

>> 6. Bug, or documentation error. "Leap Seconds" are mentioned as
>> ignored in text under the datenum function, but leap seconds apply to
>> many APIs and what "ignored" means is ambiguous. If it is decided that
>> a particular day will have 86401 atomic clock-defined seconds does
>> "ignored" mean the seconds counter ranges 0:86400 instead of 0:86399?
>> Or does it mean the clock is ever after out of step with the world's
>> rotation and almost all other clocks in the world? Or does it mean the
>> system on which Octave is running has slowed its timing services for a
>> few hours or days to remain in sync with the accepted world standard
>> time.
>
> It simply means that in the context of the datenum function, every day
> is exactly 86400 seconds. The following two expressions return the same
> datenum value:
>
>     datenum (2016, 12, 31, 15, 59, 60)
>     datenum (2016, 12, 31, 16, 00, 00)

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.

(*) 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.

Ian


Cheers... Ian