[Scilab-users] Inverse of getdate()?

[Rafael Guerra]

Hi Samuel,

For the record, performed the following test in Linux:

Computed seconds from epoch to the "present" UTC date/time:
$ date -d "UTC 2017-08-14 19:58:02" +%s
1502740682

Converted epoch back to UTC date/time to QC:
$ date -d @1502740682 -u
Mon Aug  14 19:58:02 UTC 2017


Tried then the above figures in Scilab:

w=getdate(1502740682);
mprintf("Y:%d,M:%d,D:%d  %02d:%02d:%02d",w(1),w(2),w(6),w(7),w(8),w(9));
ans =
      Y:2017,M:8,D:14  21:58:02    // result is in PC time zone +2h, not UTC (19:58:02)

round((datenum(2017,8,14,19,58,2) - datenum(1970,1,1))*86400)
ans  =
      1502740682.    // correct result obtained if UTC time is input, not the PC time zone

So, the preliminary conclusion is that getdate does take in account the leap seconds but outputs results in local PC time zone.
In order to apply the inversion formula with datenum, one needs to correct for the PC time zone difference so that the input is in UTC time.

This mix of time references does not seem very transparent to the user.

Regards,
Rafael

From: users [mailto:users-bounces at lists.scilab.org] On Behalf Of Samuel Gougeon
Sent: Monday, August 14, 2017 3:31 PM
To: Users mailing list for Scilab <users at lists.scilab.org>
Subject: Re: [Scilab-users] Inverse of getdate()?

Hello Rafael,

Le 14/08/2017 à 09:07, Rafael Guerra a écrit :
Hello Samuel,

Thanks a lot for the responses.

I am bit confused about the leap seconds, getdate seems to handle those but datenum formula below might ignore them?

Who is not so? There is a lot of work to do tests, look at the code, etc to properly document time functions and their time referentials. By the way, time features depend on the OS (references @ http://bugzilla.scilab.org/8797).
Some issues with getdate(..):

  *   getdate(N) with N a Unix time, takes the time zone into account, while the Unix time refers to the Universal Time. This is mislealing, even puzzling.
  *   getdate() and getdate(getdate("s")) return the same result. This means that all getdate(..) syntaxes take the time zone into account. The help page documents only this dependency for the getdate(N) syntax

This was longly discussed @ http://bugzilla.scilab.org/8898. The documentation still needs to be improved.
In addition:

  *   The dependency to the Daylight Saving Time must be tested and documented
  *   The fact that leap seconds are taken into account must be tested. May be it is actually the case for the getdate("s") syntax for the current date (as documented: but to be confirmed after designing a test), but not for other syntaxes like getdate(N), or for datenum(..)...
If you have time to do tests and build examples, you are welcome! :)

Samuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20170814/0dc51942/attachment.htm>