How to change email address?
--
in Control, on Time and in Sync
Stephen Scott
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https
0, I don't see how this can be right... Leap seconds
happen during the day for most time zones...
On Fri 2018-07-20T16:11:12-0400 Stephen Scott hath writ:
What I am asking is WHY.
Where is the standard for that?
Or at least some document that specifies that?
On Mon 2018-07-23T14:05:13+0100 Tony
On 2018-07-20 14:16, Warner Losh wrote:
On Fri, Jul 20, 2018, 12:05 PM Stephen Scott
mailto:stephensc...@videotron.ca>> wrote:
I would agree and I am not a fan of leap second smearing.
A.) For an application that depends on an accurate frequency
reference smearing o
.
While there is no perfect answer, it seems that Microsoft Azure servers
got it right for the last one, incorporating the leap second just before
midnight local time.
Control, on Time and in Sync
Stephen Scott
On 2018-07-20 08:03, Nero Imhard wrote:
scs...@eskimo.com schreef op 2018-07-20 11
out TF.460-1 and the IERS Bulletin C I
have problems with the delta changing any place other than after the
change, a point where the count rolls over to zero.
The math should be executed to conform to the published standards and
documentation.
-Stephen Sc
Hello Steve;
Your computer must have a clock time error or teh network is extremely,
extremely slow.
The message timestamped 2017-01-04 20:39 was received at about
2017-01-05 16:57-05:00
-Stephen
On 2017-01-04 20:39, Steve Summit wrote:
Martin Burnicki wrote:
If we don't look only at the
NOT "unintentional"
-S
On 2016-12-30 11:37, Brooks Harris wrote:
On 2016-12-28 04:16 PM, Steve Allen wrote:
On Wed 2016-12-28T16:00:17 -0500, Brooks Harris hath writ:
I don't think so. This is POSIX so-called "1970-01-01 00:00:00 UTC"
not 1588/PTP. 1588/PTP epoch is 10s earlier.
At
Hello Brooks;
On 2016-12-28 12:33, Brooks Harris wrote:
On 2016-12-26 08:28 PM, Tony Finch wrote:
Brooks Harris wrote:
The time_t 1970 epoch is fixed with respect to internal POSIX calculations,
but it "slips" a second with respect to UTC with each (positive) Leap
Hello Brooks, Stephen;
What's all this discussion about precision?
The smear has tossed the precision of the second SI out the window.
This is totally unacceptable for an application that requires a precise
and stable frequency reference (telecommunications and broadcast for
example).
.
This is a local decision for a local time.
I am not aware of any international standards that touch the subject.
I would be interested in learning about other jurisdictions that may
have published a policy.
*Stephen Scott*
On 2015-02-05 09:35, Kevin Birth wrote:
Wednesday, July 1, at 9:00
Since UTC is defined by the IERS before 1972-01-01 beginning_of_utc is not
appropriate.
This is the beginning of integer leap seconds, not UTC.
How about leap_second_epoch or if the term epoch is undesirable leap_seconds_origin
labelled as leap00
Stephen*
*
On 2015-01-25 13:11, Rob Seaman
time zones.
-Promote standards for the communication of all UTC time corrections
including leap seconds and standard / daylight saving time shifts.
The difficult can be done today, miracles tomorrow, and the impossible
will take a bit longer and many committee meetings.
REGARDS*
Stephen
On 2014-01-18 16:14, Peter Vince wrote:
Stephen Scott has just mentioned his involvement in the TV industry in
the USA, with its problematical 29.97 Hz frame-rate. I also work in
the TV industry, but in the UK where we are lucky to have a nice
integer 25 Hz rate. Although historically we
timescale means that a leap second insertion is
equivalent to inserting 29.97002997... video frames.
3.)This rate implies in a non-integer number of video frames in a 24
hour day and thus a varying phase alignment to a 24 hour clock.
Regards
Stephen
--
*Stephen Scott*
Skotel Corporation
14 matches
Mail list logo