![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
scottobear
BHK seems to really like Orioles!
She and I went to Geppi's ( http://www.geppismuseum.com/ ) and the Ravens / Orioles Stadium was between the parking and the entrance - see also, the Babe Ruth Museum, not shown.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Gabby Hayes has been a running gag for us, since before we were married.
in other news -
According to Bulletin C of the International Earth Rotation Service:
A positive leap second will be introduced at the end of December 2008. The sequence of dates of the UTC second markers will be:2008 December 31, 23h 59m 59s
The difference between UTC and the International Atomic Time TAI is:
2008 December 31, 23h 59m 60s
2009 January 1, 0h 0m 0s
from 2006 January 1, 0h UTC, to 2009 January 1 0h UTC : UTC-TAI = - 33s
from 2009 January 1, 0h UTC, until further notice : UTC-TAI = - 34s
This means that tomorrow, 3:59:59 PM PST will be followed by 3:59:60 PM PST prior to the advent of 4:00:00 PM PST.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2009-01-05 06:31 am (UTC)Um.. is this a repeating change, or a one time phenomena? are there programming implications - Java VM updates? If I have to start worrying about updating code for leaping seconds I'm not going to be happy..!
no subject
Date: 2009-01-05 01:59 pm (UTC)http://www.timeanddate.com/time/leap-seconds-future.html
more info here, too.
http://www.timeanddate.com/time/leapseconds.html
it seems that due to the earth slowing down, they evaluate every 6 months whether or not to add a leap second. 24 have been added (so far) since 1972.
As for programming implications... that's a really good question.
via wikipedia (http://en.wikipedia.org/wiki/Leap_second ) -
Several arguments for the abolition have also been presented. Some of these have only become relevant with the recent proliferation of computers using UTC as their internal time representation. For example, currently it is not possible to correctly compute the elapsed interval between two stated instants of UTC without consulting manually updated and maintained tables of when leap seconds have occurred. Moreover, it is not possible even in theory to compute such time intervals for instants more than about six months in the future. This is not a matter of computer programmers being "lazy"; rather, the uncertainty of leap seconds introduces to those applications needing accurate notions of elapsed time intervals either fundamentally new (and often untenable) operational burdens for computer systems (the need to do online lookups) or insurmountable theoretical concerns (the inability in a UTC-based computer to accurately schedule any event more than six months in the future to within a few seconds).
A counter to this argument is that computers need not use UTC. They could use TAI or GPS time and convert to UTC or local civil time as necessary for output. GPS time is an especially convenient choice, as inexpensive GPS timing receivers are readily available and the satellite broadcasts include the necessary information to convert GPS time to UTC. It is also easy to convert GPS time to TAI as TAI is always exactly 19 seconds ahead of GPS time.
Examples of systems based on GPS time include the CDMA digital cellular systems IS-95 and CDMA2000.
So... I guess it depends on what time system is in use.