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:[email protected]] On Behalf Of Samuel Gougeon
Sent: Monday, August 14, 2017 3:31 PM
To: Users mailing list for Scilab <[email protected]>
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
_______________________________________________
users mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/users
