Your skill will accomplish
what the force of many cannot
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:
But that figure diverges a way from the one used by your C# snippet. It seems to calculate the year as:
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.