Re: Hodie!

On Thu, 12 Feb 2009 10:49:56 +0100, Abigail <abigail@abigail.be> wrote:

> On Wed, Feb 11, 2009 at 05:38:12PM -0700, Tom Christiansen wrote:

>> Here's what it is: your computer's internal time (a.k.a. "the
>> epoch", measured in number of seconds since 1970) hits the
>> unique figure of 1234567890, thus lining up all the digits the
>> same way they're lined up at the top of your keyboard.

>> Isn't that *special*? :-)

> It is.

Thanks.

> Yesterday at $WORK, I checked in a file containing tests, that
> has in its preamble:

>   my $EPOCH  = freeze_time (1234567890);  # Fri Feb 13 23:31:30 2009

> Might as well pick a 'cute' value if your tests are going to
> fake a known point in time.

Kinda like 0xDEADBEEF, eh? :-)  [But *why* can't we use 0Xdeadbeef!?]

What struck me was how uncannily well the two points line up
in decimal, with just a wee shift in the 78 walled of with a
pair of 0's:

      1234560780
      1234567890

It was also curious seeing that as far as Damian (for whom 
the code's naming, comments, and structure were designed :) 
and Nathan go, these are going to occur on St Valentine's Day!

Assuming Damian's in Australia/Melbourne....

    I was born at    E -217132020: Wed Feb 13 15:33:00 CST 1963.
    Next birthday at E+1234560780, Sat Feb 14 08:33:00 EST 2009.
    Magic moment is  E+1234567890: Sat Feb 14 10:31:30 EST 2009.

Assuming Nathan's in Pacific/Auckland....

    I was born at    E -217132020: Wed Feb 13 15:33:00 CST 1963.
    Next birthday at E+1234560780, Sat Feb 14 10:33:00 NZDT 2009.
    Magic moment is  E+1234567890: Sat Feb 14 12:31:30 NZDT 2009.

IIRC, Nathan's wife even *missed* a birthday once, flying over 
the International Date Line.  Travellers beware! :-)

Which all goes to show how important it is than *in code* one must
*always* use epoch or gmtime time internally, relegating localtime for 
display purposes alone and at most.  Otherwise each day seems to span
50 (FIFTY!) hours, ranging from UTC+14 .. UTC-12 and spanning the IDL.

Using anything but epoch time is--well, dodgy as a dancing dingo. :-)

--tom
-- 

    It is inappropriate to require that a time represented as
    seconds since the Epoch precisely represent the number of
    seconds between the referenced time and the Epoch.

            IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

• hodie by Tom Christiansen
• Re: hodie by Abigail
• Re: Hodie! by Tom Christiansen
• Re: Hodie! by Zefram