http://www.perlmonks.org?node_id=1000999


in reply to Calculate clock ticks since a given date

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:

And that lot come from just one Wikipedia page.

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.

RIP Neil Armstrong

Replies are listed 'Best First'.
Re^2: Calculate clock ticks since a given date
by syphilis (Archbishop) on Oct 26, 2012 at 09:07 UTC
    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.

      RIP Neil Armstrong

        You could adjust the height of the weight by horseshoe shimming between brazed nut and weight to shorten the stroke.Unless of course they brazed nut to weight

Re^2: Calculate clock ticks since a given date
by kurgan (Sexton) on Oct 26, 2012 at 06:30 UTC

    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.

      RIP Neil Armstrong