Subject: leap second OR the minute does NOT always have 60
seconds - msg#00033

List: science.geophysics.otas.general

Mail Archive Navigation:
by Date: Prev Next Date Index by Thread: Prev Next Thread Index

This is my first text of "Seismology 101 to otas".
Post here your correction, opinion, tip or question. Some of
the questions can be put in a future FAQ.

A more mature version of this document will be "archived"
into the project or something like that.

Thanks

Jose Simoes
"Time is the Simplest Thing" Clifford Simak

*******

Public: Someone with a good scientific and/or technical
background but no specific knowledge in Geophysics or
Astronomy.

*******

As a rule when we have scientific data in relation with
time, we use UTC (Coordinated Universal Time or Universal
Time Coordinated) and only UTC.

UTC is more or less the same of GMT (but the use of the term
GMT should be deprecated and is, unfortunately, widely use
today, just by tradition I think).

People that lives in London, now, have UTC in their watches.
People in S. Francisco are running on UTC-8.

Of course UTC does not follow any "daylight saving time",
and has a 24h format (no am/pm).

An the date should follow UTC. For exemple, the deadliest
earthquake of Tangshan (S. China) was felt at 3:42 a.m. on
July 28, 1976, by the people that live there, but, in the
catalogs is shown in July 27 (now China - all China, all
year - follows UTC+8, I am not sure about the time used
back in 1976, but it does not matter if you always use
UTC).

The rotation of the Earth can change a little, from a
variety of reasons (there is a recent urban legend about
earthquakes changing in the rotation of the Earth, but I am
not commenting that at this moment), sometimes as much as a
second in a year.

To compensate that (all in all our daily activities are
linked to the sunrises and sunset, so linked to the
rotation of the Earth) an "extra" second can be added
or subtracted to UTC.

This is analog to the "leap year" where a day is introduced
to keep the calendar more or less synchronized with the
seasons (and with some religious ceremonies, that are
correlated with the seasons)

If we added a "leap second" a "correct" clock should
show something like (1 line = 1 second)

1997 June 30, 23h 59mn 59s
1997 June 30, 23h 59mn 60s
1997 July 1, 0h 0mn 0s
1997 July 1, 0h 0mn 1s

If we subtract a "leap second" a "correct" clock should
show something like

2009 June 30, 23h 59mn 57s
2009 June 30, 23h 59mn 58s
2009 July 1, 0h 0mn 0s
2009 July 1, 0h 0mn 1s

The added second is called a "positive leap second". The
second case is a "negative leap second".

Before 1972 things were different, but fortunately in OTAS
we are not dealing with that distant past. No "negative
leap second(s)" were ever introduced to our clocks.

But when is a seconds added or subtracted?

Unfortunately we cannot predict in advance the changes in
the rotation of the Earth. But we can monitor it and
compensate sometime after the changes taking place.

As a result from time to time a "leap second" is
announced and posted at

http://www.iers.org/iers/publications/bulletins/bull_c

I took one of my previous examples from "bulletin 13". that
can be seen at:

http://hpiers.obspm.fr/eoppc/bul/bulc/bulletinc.13

A list of past "leap seconds" can be found in

http://hpiers.obspm.fr/eop-pc/earthor/utc/UTC-offsets_tab.html.

Usually announces are made 6 months or so in advance, even
if no leap second is going to be introduced.

The leap second can be introduced in the end of December or
in the end of June. If really REALY needed that can also
be introduced in the end of March or in the end of
September, but that was never been the case, at least since
1972.

One leap second, if introduced, is always introduced at the
end of the day at the end of the month, as the two previous
examples show.

Those are the rules now, but that can change in the future
(as they have changed in the past).

In the last decade of last century one positive leap second
was introduced, roughly, once a year. This millennium we
haven't had a leap second yet.

The last announce was made in Paris the 14th of January
2005, stating NO leap second from now to the end of June /
beginning of July 2005.

Is difficult to know, when doing calculations with time, if
the software we are using takes leap seconds in
consideration. Generally they do NOT (is easy to understand
why, since future leap seconds can not be predicted with a
lot of time in advance).That includes *ix operating systems
and C/C++ built in functions.

Several ISO standards are incompatible with leap seconds...

The Standard C, however, states that the seconds is an
integer that can change between 0 and 61, allowing a
positive leap second (and even a DOUBLE leap second).

GPS satellites do not use UTC stritly, but the GPS receivers
do the necessary conversion to UTC (GPS receivers are now
the most used source of UTC in seismology and in IT)

In seismology, ONE second matters. So, if I have to
calculate the time difference between June 30 23:59:58 and
July 01 00:00:01, the correct answer is "it depends of a
possible leap second"

Question: What is the probability that all this have some
influence in a given alarm?
Answer: Slim but not zero

Question: So I can ignore this?
Answer: You write the software, you take the responsibility.
Note that a program can fetch the corrections from the
Internet.

A few more links:

http://www.iers.org/iers/products/eop/leap_second.html
http://www.ucolick.org/~sla/leapsecs/onlinebib.html
http://tycho.usno.navy.mil/leapsec.html

A list of the "positive leap seconds in the past" (since
1973)

1974 Jan.
1975 Jan.
1976 Jan.
1977 Jan.
1978 Jan.
1979 Jan.
1980 Jan.
1981 Jul.
1982 Jul.
1983 Jul.
1985 Jul.
1988 Jan.
1990 Jan.
1991 Jan.
1992 Jul.
1993 Jul.
1994 Jul.
1996 Jan.
1997 Jul.
1999 Jan.
(all positive leap seconds)

no leap second after 1999 Jan to 2005 Jul

a leap second is possible in Dec 2005 / Jan 2006 but we have
to wait until around next July to find out. A leap second
is also possible in the beginning of October, but that is
very VERY unlikely. No leap second is possible before that.

END - the following are ads...

O SAPO já está livre de vírus com a Panda Software, fique você também!
Clique em: http://antivirus.sapo.pt

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Thread at a glance:

Previous Message by Date:

Re: Rationale for a P2P system

On Tuesday 18 January 2005 07:46, Stu Statman wrote: > I think it's more than just sideways communication ... I don't think we > want to place any limits on data sources, or on how the data is > processed. Just to expand on Stu's point how I see it. Have we decided who the end users will be yet? Unless we can expect a very high level of reliability and up-time from them I don't see how a centralised system can be trusted. On the other hand, if we only expect large organisations to run the software who might well be around 24/7/365 then I completely agree that P2P will not be worth the hassle. A large organisation might also be more willing to absorb the costs of machine maintenance and bandwidth over many years, after all I don't think many are expecting another tsunami for quite some time. > Here's of a vision for you : > > We should be able to publish out simple blueprints for detection > devices. Electronics hobbyists should be able to build them, and hook > them into the OTAS network. And the network should be able to absorb > that data, assess it for reliability, and generate appropriate warnings. > > > Am I being absurd? I really don't think the idea is absurd but we would need to consider a 'degree of trust' that home made detection would be given and only if several devices agreed with almost certainty of an event should their data be examined. Even then it might need to be interpreted differently because of a reduced accuracy. > Charles Martin wrote: > >I don't think the big issue is imposing excessive load on the seismo > >or warning servers. A seismo data point is < 100 bytes; the tsunami > >warnings from the Pacific operation are less than 1K; and I don't > >think we need to have hundreds of data-aggregators hitting those > >sites. > > > >It's the desire of high avaiability under the odd conditions were > >talking about thatg makes me think some sideways communication is > >useful. I'm not talking about tryhingt to do BitTorrent 0or something > >,,, just pass alerts to a few partners on the same level. > > > > > >On Mon, 17 Jan 2005 21:48:58 -0800 (PST), John M. Gabriele > > > ><john_sips_tea-/E1597aS9LQAvxtiuMwx3w@xxxxxxxxxxxxxxxx> wrote: > >>--- Chris <chrios-ur4TIblo6goN+BqQ9rBEUg@xxxxxxxxxxxxxxxx> wrote: > >>>[snip] > >>>I see a lot of people are chiming in with P2P ideas, but I don't > >>>believe this system will benefit from a P2P architecture. > >>>[snip] > >> > >>Thanks for the post Chris. I think you're right (though please > >>take what I say with a grain of salt, since I'm just an amateur > >>here). > >> > >>It's tempting to think that, when there is another quake, the > >>handful of trusted data sources you mention would get slashdotted > >>and no one would be able to get the data they need when they > >>need it most. > >> > >>Maybe because we hear about it so much on /. or maybe just > >>because folks like writing p2p software. Dunno. > >> > >>I'd be curious to see some numbers from the sources themselves > >>on the network traffic before and during the recent tsunami tragedy, > >>but I'd bet that the only folks slashdotting them were university > >>geology departments, and that data was available throughout. ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Next Message by Date:

Re: Rationale for a P2P system

--- Stu Statman <gurustu-fOdFMYwuEsI@xxxxxxxxxxxxxxxx> wrote: > > I think it's more than just sideways communication ... I don't think we > want to place any limits on data sources, or on how the data is > processed. We shouldn't simply be handling alert broadcasts, but also > the raw data. Ah. Whoops. There's the distinction. Sorry, I missed it before. If we're just looking at alert broadcasts, then someone should be able to throw together a little non-P2P app that can just ping warning centers ( http://tsunami.gov/ ? ) looking for new alerts and we're done. (I suppose this has already been done with that tsunami warning widget http://download.progsoc.org/ .) I'm guessing that there are experts already looking at and processing raw data for us, of course. If we're working solely with raw data -- seismic activity data -- then the there's some number crunching to be done. Will it be serious math that takes an average computer a non-trivial amount of time to process? If yes, then it's a waste to have everyone doing that same processing. Perhaps the easiest course of action is to first pretend that the processing will be trivial, and write an app that grabs the raw data, processes it, and then comes up with stuff like where the epicenter is, if tsunamis are likely and which direction they would likely propagate. Then later, if we find that it takes an "average computer" (I'm thinking 400 MHz PII) more than n minutes, we can then figure out some sort of P2P scheme to distribute the load. This way, we can divide up tasks and get to work fast: - pick a language, GUI toolkit, and get a skeleton app together, - figure out where our raw data sources are, - figure out how to get the data and collate it, - figure out how to process it into something useful - draw that data into a pretty picture in the main skeleton app's window Stu, regarding your idea/vision for detection devices, what I think you're talking about is having little seismometer + computer boxes. But maybe I'm understanding you wrong. If that's what you mean, I figured that's beyond the scope of this project. Ok, I need to read more now and stop typing. > I don't think our goal should be just another way of > communicating the data out, but something more revolutionary : expanding > the data that is processed, distributing the processing requirements, > providing a distributed network to replacte the data, and *then* a > system to broadcast alerts. > > Here's of a vision for you : > > We should be able to publish out simple blueprints for detection > devices. Electronics hobbyists should be able to build them, and hook > them into the OTAS network. And the network should be able to absorb > that data, assess it for reliability, and generate appropriate warnings. > > > Am I being absurd? > > > Charles Martin wrote: > > >I don't think the big issue is imposing excessive load on the seismo > >or warning servers. A seismo data point is < 100 bytes; the tsunami > >warnings from the Pacific operation are less than 1K; and I don't > >think we need to have hundreds of data-aggregators hitting those > >sites. > > > >It's the desire of high avaiability under the odd conditions were > >talking about thatg makes me think some sideways communication is > >useful. I'm not talking about tryhingt to do BitTorrent 0or something > >,,, just pass alerts to a few partners on the same level. > > > > > >On Mon, 17 Jan 2005 21:48:58 -0800 (PST), John M. Gabriele > ><john_sips_tea-/E1597aS9LQAvxtiuMwx3w@xxxxxxxxxxxxxxxx> wrote: > > > > > >>--- Chris <chrios-ur4TIblo6goN+BqQ9rBEUg@xxxxxxxxxxxxxxxx> wrote: > >> > >> > >>>[snip] > >>>I see a lot of people are chiming in with P2P ideas, but I don't > >>>believe this system will benefit from a P2P architecture. > >>>[snip] > >>> > >>> > >>Thanks for the post Chris. I think you're right (though please > >>take what I say with a grain of salt, since I'm just an amateur > >>here). > >> > >>It's tempting to think that, when there is another quake, the > >>handful of trusted data sources you mention would get slashdotted > >>and no one would be able to get the data they need when they > >>need it most. > >> > >>Maybe because we hear about it so much on /. or maybe just > >>because folks like writing p2p software. Dunno. > >> > >>I'd be curious to see some numbers from the sources themselves > >>on the network traffic before and during the recent tsunami tragedy, > >>but I'd bet that the only folks slashdotting them were university > >>geology departments, and that data was available throughout. > >> > >> __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Previous Message by Thread:

Rational for a P2P system

Having read through much of the mailing list, wiki, and blog content, I felt it was time to add my two cents. Instead of sending me hate mail, just consider what I have to say :). The more we hammer out the core functionality, and develop the rational for whatever architecture we choose, the easier and cleaner the implementation will be. Chris ---------------------- I see a lot of people are chiming in with P2P ideas, but I don’t believe this system will benefit from a P2P architecture. There are a handful of trusted centers, which provide seismic and oceanographic data, and this is where OTAS would fetch its data. It wouldn’t make sense to have a P2P network sharing this data. Not only does it make the system more complex, but more susceptible to invalid or falsified data. If OTAS were to generate a false alert, peoples’ lives could be lost in the resulting mayhem, and would undermine the reputation of the alert system. This is not an option! Because of the above comment, I believe that users clients should NOT have the ability to “vote” or generate alerts (i.e. thousands of people reporting a tsunami). Regular people are not experts, and any system that uses “voting” is susceptible to hacks. For tsunami predictions, warnings, and alerts, lets leave it up to trusted sources and experts (if the experts are awake…). Consider a P2P 5-day forecast system (which as far as I know, does not exist). Data is ultimately supplied from a small number of trusted sources (i.e. weather.gov). A P2P system would have to fetch the data from here first. Since the reliability of any network is determined by its weakest link, if a network failure were to compromise the data sources, we would at best be able to pass around out-of-date information. Luckily for us, the Internet (and routing in general) is rather robust. If our hypothetical 5-day forecast system fetched weather information from a few different sources, we’d have a highly reliable system even without a P2P infrastructure. A P2P system works well in some types of catastrophic network failures. A P2P system that could exchange data locally makes sense in a situation where isolated groups still had local connectivity, but were disconnected from the greater internet (and thus no long have enough data sources to warrant a legitimate alert), However, this only works if peer nodes can generate useful information. Perhaps in a tornado warning system where each peer was reporting wind speed, even an isolated network might be able to provide useful information that it could disseminate to others in the local area. However, if you consider our application, a tsunami alert system, this idea doesn’t carry over. The kind of data we need is only supplied by a handful of trusted data sources (which are the only ones capable of giving us tsunami-related information). Peers in a hypothetical P2P OTAS system wouldn’t be able to add anything; they’d merely be able to pass on data. In an isolated group, it’s likely that all the other peers also received the latest data snapshot. You might think that a P2P system would work well in isolated networks for newly logged-on clients (perhaps in response an initial tsunami hit). Yes, they could receive the latest data snapshot that the isolated peer group would have to offer, but that’s assuming they could even get on at all. Remember, even a P2P system needs a “staging ground” to help peers find each other. The likely hood that one of these P2P servers is “trapped” in the isolated network is low, and so nothing would work. Think how many you’d need to have decent coverage! It’s simply not an option. Since tsunamis only manifest themselves on the shore (there are no waves generated at sea), transocean network connections are not vulnerable, which means only network infrastructure on shorelines would be susceptible (and would likely be destroyed when the tsunami hit). Because of this, I feel it is safe to assume we are running on a reliable network before the tsunami hits. This means we can deliver the warning reliably without P2P connectivity. Once the tsunami is hit, electrical and telecom infrastructure would be devastated. Small pockets of connectivity would exist, but what kind of data of any use would they be able to share? Clearly OTAS would be used to alert areas not yet affected. Chris ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Next Message by Thread:

P2P?

This is what I would imagine as the OTAS network purpose and structure: Perhaps a dozen reliable ~24/7 servers essentially providing geographical diversity more than anything else. These servers would essentially act as mirrors for the collective data received from all available seismological centers. For example, if the trans-pacific fiber lines were damaged and the connection from Japan to Hawaii was broken. This little web of servers could route the missing information the “other way around the world”. In essence, we’re building a reliable (because there would be several routing paths) and distributed database, where the servers make sure they are all providing the latest data and correct data. Just a subtle note on the last point. With a dozen different servers fetching data every-now-and-again from the various seismological centers, not only to we have a distributed data source, but also one that can ensure the data they received is valid. I could imagine some malicious person tampering with outgoing data from some seismological center, but it would be very hard to tamper with every data request. This means perhaps half our servers would get real data and the other half get fake data. They could then communicate and determine if the source was compromised. Again, I stress that this system cannot under any circumstances generate false alerts. I don’t think we’ll need anything like grid computing. We’re building a tsunami alert system, not the next generation internet here. :) I think computation would be simple (although I’m not a seismologist). We could either do this client side, server side, or both. Again, I think it would be a bad idea to have a client side vote (like 1500 people finished computation and a tsunami is about to hit manhattan). I think anykind of voting system is succeptable to hacking (I don’t care how good it is). In a mission critical application like this, I don’t think it’s an option. However, this doesn’t mean we can’t let clients do some processing and then even corroborate their result with the server’s result. In fact, this might be our best option. I foresee a little GUI that has a world map on it with dots for all the reporting seismological centers. Each is perhaps labeled with a color seismological disturbance and a time. So if you are living in Hawaii and you see a ring of stations with red icons around you, perhaps: San Francisco, CA - Red - 10:13 PM Anchorage, Alaska - Yellow - 11:23 PM Sydney, Australia - Red - 11:34 PM Tokyo, Japan, - Red - 11:02 PM And some predicted epicenter about 450 miles south east of you, and OTAS reporting that conditions merit an alert, + official alerts (if they aren't sleeping) = Time to seek higher ground. (I’m feeling creative, so maybe I’ll post a mockup and post it on the wiki tonight). So what would the clients do? I don’t think they need to be P2P with each other. But they would certainly tap into our distributed server backbone. This would provide multiple redundant routing paths, and once we could connect to one server, we effectively connect to all of them (we could even have some distributed digital signature from a majority of the servers certifying the data.) Ideally, we could (and likely would be able to) connect to a few servers, even if some major trunk lines were down. Now, don't get me wrong, I think we should gather some distributed information. I could also foresee clients (optionally) relaying back tidal (surf) conditions to the server (perhaps wave intensity, height, and tidal distance (tide in, out, really in, or really out). If we're seeing half a million people reporting that the tide has retracted 50 meters, that might be interesting... However, at least for the initial incarnation, I don't think we should use this data for generating alerts (the other data sources should be more accurate and reliable anyway). But building in a reporting system would be useful none-the-less, even as a spring board for future features. I think this is our best bet. (Let the emails begin!) Chris ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Subject: leap second OR the minute does NOT always have 60seconds - msg#00033