Perl Monk, Perl Meditation PerlMonks

### Calculate clock ticks since a given date

by kurgan (Sexton)
 on Oct 26, 2012 at 05:00 UTC Need Help??
kurgan has asked for the wisdom of the Perl Monks concerning the following question:

Hello all,

Maybe I am not searching for the correct terms, but I have Google'd many variations and can not seem to find a way to convert from any time in Perl to Clock Ticks.

I have been tasked with the job of handing out the current UTC time from within Perl in ticks (the epoch being 01/01/0001 00:00:00, not 01/01/1970 00:00:00).

It is late and I have been ill, so maybe I am just brain dead, but I can not seem to come up with a reasonable solution.

I have seen the equation:

epoch = (DateTime.Now.ToUniversalTime().Ticks - 621355968000000000) / 10000000;

But this is in C#, not Perl (I must remain strictly in Perl for this project).

Any help would be GREATLY appreciated!

```>perl -e "use bignum; \$e=time; \$t=(10000000*\$e)+621355968000000000; pr
+int \$t;"
634868272130000000
Which does not give the desired granularity...

Replies are listed 'Best First'.
Re: Calculate clock ticks since a given date
by BrowserUk (Pope) on Oct 26, 2012 at 06:08 UTC
convert from any time in Perl to Clock Ticks.

You say that as if "Clock Ticks" were some universally defined SI time unit. But ticks of which clock?

I have a Grandfather clock that ticks once every 2 seconds, (and tocks every two on the alternate second). But it also looses around 30 minutes a day.

Conversely, the clock on my PC ticks (or maybe tocks; I've never heard it :), 2.4 billion times a second

I have been tasked with the job of handing out the current UTC time from within Perl in ticks (the epoch being 01/01/0001 00:00:00, not 01/01/1970 00:00:00).

Naively, (assuming "Clock Ticks" are seconds), you only need add the number of seconds between 0001 and 1970 to those returned by time:

```print 1969*365.25*24*60*60;;
62136914400

But that figure diverges a way from the one used by your C# snippet. It seems to calculate the year as:

```print 62135596800 / ( 1969*24*60*60 );;
365.242254951752

Or 365 days 5 hours 48 minutes 57 seconds.

But a quick search comes up with a bunch of different figures:

• 365 solar days, 5 hours, 55 minutes, 12 seconds
• 365 solar days, 5 hours 49 minutes 19 seconds.
• 365 solar days, 5 hours, 55 minutes, 58 seconds.
• 365 solar days, 5 hours, 48 minutes, 45 seconds.
• ```1985–1986    365    5    48    58
1986–1987    365    5    49    15
1987–1988    365    5    46    38
1988–1989    365    5    49    42
1989–1990    365    5    51    06
• 365 days, 5 hours, 48 minutes, 45.19.

And then there is the problem that up until 1582, the calender was so wrong they had to keep adding leap weeks (or was it leap months) to to stop New Year's Day from inexorably shifting its relationship with the solstices.

On top of that, the length of the day is variable.

My point is that whatever numbers you use, what you've calculated as your "epoch" is effectively a totally arbitrary point in time.

So then you have to question: why are you doing it?

1970 as used by *nix; or 1601 as used by Windows; or any of the other Notable Epochs are just as good (and bad).

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
I have a Grandfather clock that ticks once every 2 seconds, (and tocks every two on the alternate second). But it also looses around 30 minutes a day.

Nothing wrong with the clock ... it's just that time itself now runs faster than it did when the clock was built ;-)

You could compensate for this by shortening the periodicity of the pendulum ?

Cheers,
Rob
it's just that time itself now runs faster than it did when the clock was built

Ain't that the truth!

You could compensate for this by shortening the periodicity of the pendulum ?

We could but for that long before it was bequeathed to us, someone broke the adjustment -- looks like they stripped the thread trying to turn the rusted on nut with pliers or similar -- and 'fixed' it by braising the nut in place.

These days it's kept -- unwound; the ticks and tocks and whirs and clunks would give the dead a bad night -- purely for its sentimental and decorative value.

(And more of the former than the latter in my opinion, but it wasn't bequeathed from my side of the family, so I don't get much say in the matter :)

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

You are definitely not going to get any argument from me on the inconsistency of time from multiple perspectives and / or histories. :)

My project comes from working with a credit card merchant (I have no voice in deciding which) requires a field in the HTML form generated from a Perl script that is based on "UTC time in ticks". I found (the best single page explanation I came across) that there are at least two generally accepted slices of the second (60 and 100) and I am being told to go with the 100.

The epoch date used by them is the 01/01/0001 00:00:00, not mine unfortunately.

I was not able to find much, so I guess epoch to "ticks" is either never converted or universally understood and I did not get the memo.

Thank you for your thoughtful response.

My project comes from working with a credit card merchant (I have no voice in deciding which) requires a field in the HTML form generated from a Perl script that is based on "UTC time in ticks".

Does the C# snippet derive from that credit card company, or just some arbitrary thing found on the web?

If not the former, you'd best ask them what the EPOCH_ADJUST_CONSTANT should be in:

```
my \$CCTime = ( time() + (\$localeOffset * 3600) ) * 100 + EPOCH_ADJUST_
+CONSTANT;

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
Re: Calculate clock ticks since a given date
by ikegami (Pope) on Oct 26, 2012 at 05:56 UTC
```>perl -E"use bignum; use Time::HiRes qw( time ); say( (10000000 * time
+) + 621355968000000000 );"
634868277695085200

This worked great! Thank you.

Unfortunately, this being done on and old Win32 box, it seems I am not going to get the full 18 digit number no matter what I do.

I had completely blocked out Time::Hires. Again, thank you!

Create A New User
Node Status?
node history
Node Type: perlquestion [id://1000994]
Approved by ikegami
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (5)
As of 2018-04-21 16:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
Voting Booth?
My travels bear the most uncanny semblance to ...

Results (81 votes). Check out past polls.

Notices?