A question for someone who knows a LOT

How are the outputs of the opcodes time/times and date/dates derived?

I know time/s begins with 0 at the start of the csound performance, while
date/s has its 0-point at the UNIX epoch 1-1-1970.

My computer is running csound on windows, so I'm not sure the unix situation
applies, but I know that unix systems typically are a few seconds out of
whack with real time-keeping standards that are actually used for critical
functions to measure time on earth (such as the atomic system). I don't know
if this applies to windows too. I don't know if the issue even comes into
csound's times and dates opcodes at all. i don't know how the source code
implements time-fetching in those opcodes on a machine level.

Am I barking up the wrong tree trying to quantify the error and adjust the
output of these opcodes so that they represent the true number of seconds
since 1-1-1970? SUch that you could call up the international time-keeping
authorities in Greenwhich and they would give you the same number of seconds
counted since that date? 
An example of one way to do this conceptually would be to download the UTC
leap-second announcements that have been made by the authorities since 1970,
then sum the lengths of all the leap-seconds that were added to the time
count, and add that constant to the dates output to get the "true" number of
seconds since 1-1-1970.

One thing I'm not sure is if these clocking mechanisms are even consistent
enough over many hours or days, multiple reboots etc. for the attempt at
adjustment to be worth making. Is it futile to try to get "true" adjustment
because the adjustment needed will be different with every csound
performance, for example? Or is this clock ticking reliably and consistently
enough in the background at all times to provide someting that could be seen
as a reliable absolute-time environmental variable?

Yeah what I'm trying to do with it is get some csound instruments to output
very accurate sets of triggers and signals to inform other csound
instruments about the current (real-time) universal astronomical time. There
are a number of astronomical time standards to pick from but I'd probably
like to adjust it to UTC, which is what the second-length of the unix
standard is based on (but alas, unix ignores the occasional leap-seconds
announced by the UTC consortium, thus unix slowly drifts away from the
actual UTC date-time but could be adjusted by a constant number of seconds).

Ideally I do not want to have to look up and input a custom time-adjustment
factor everytime I run the csound command. I want the code to do the work
for me, perhaps using the file-input opcodes. Then I could just add one line
to a file everytime the UTC issues a new leap-second announcement.

Again the opcode I'm really talking about here is dates/date. It puts out
the time elapsed since 1-1-1970 in seconds or as a string. Date runs at
i-time so the idea is to use times (running at k-rate - outputs seconds
elapsed since start of performance) to augment the time that date spits out
in the first second of performance. Then the performance can proceed in
real-time with a running count of absolute time provided in a k-rate
variable.

Thanks in advance for help, suggestions and insight.



-----
***cybilopsin***
"We are all guilty of crime, the great crime of not living life to the full." - Henry Miller
--
View this message in context: http://csound.1045644.n5.nabble.com/date-and-time-opcodes-adjusting-to-UTC-tp5756229.html
Sent from the Csound - General mailing list archive at Nabble.com.

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here