Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sunybcs!boulder!pikes!aspen.craycos.com!sphere!ruck
From: ruck@sphere.UUCP (John R Ruckstuhl Jr)
Newsgroups: sci.electronics
Subject: Re: time accuracy in telephone service billing
Message-ID: <292@sphere.UUCP>
Date: 1 Jun 90 09:40:40 GMT
References: <285@sphere.UUCP>
Distribution: world,to.sphere
Organization: Private; Colorado Springs, CO
Lines: 39

In article <285@sphere.UUCP>, ruck@sphere.UUCP (John R Ruckstuhl Jr) writes:
> How do long-distance telephone services maintain accuracy in
> time-stamping telephone connections?
> Precisely, how, and how often, are such clocks set, and what is their
> accuracy?

Someone writes me: why worry about time precision --

> I thought that billing changed with the time - if you make a phone call
> at 4:58 that lasts for 10 minutes, you get the connect charge and the
> first two minutes at the daytime rate, then the last 8 minutes at the
> evening rate.

For domestic long-distance telephone calls,
    AT&T and MCI adjust the billing rate (as described above).
For international long-distance telephone calls,
    AT&T and MCI bill at the rate in effect when the call is placed.

The time of connection would also important if the first minute of 
connection time is billed at a different rate than subsequent minutes.

So I'm looking for assurance that when I place a telephone call at
17:00:30 I will be billed at the discounted rate, that a time-of-day
error (I'm not concerned with elapsed-time) cannot occur on the 
long-distance provider's billing computer.

Someone else writes or posts, very politely: this might belong in
comp.dcom.telecom.

Thank you -- I hadn't known that and hadn't recognized it from the
description I had (not to say I shouldn't have recognized it):
comp.dcom.telecom	Telecommunications digest. (Moderated)

But for now I continue what I've begun, here (until it dies, unresolved, 
and I'm forced to expand this host's limited feed to include that 
newsgroup (not to say that would be bad (smiley))).
-- 
John R Ruckstuhl, Jr	UUCP: sphere!ruck
			DOMAIN: ruck%sphere@hp-lsd.cos.hp.com