On 19 July 2018 at 11:24, Martin Burnicki wrote:
> As far as I know, UTC-SLS is done locally on a client, and since it's
> implemented in a Java runtime it is only "seen" by Java applications.
>
> This means if you get timestamps in Java and non-Java applications on
> the same machine then they ma
On 19 July 2018 at 09:44, Hal Murray wrote:
>> As a IT professional, and author of date/time libraries, I cannot stress
>> enough how much a standard is needed here. We are going to have both UTC
>> (with leap seconds) and systems that smear ("UT-Smear") and there is
>> currently no agreed way to
"In addition, there is no standard method for applying this frequency
adjustment, so that different implementations may disagree among
themselves in addition to the time error with respect to UTC."
As a IT professional, and author of date/time libraries, I cannot
stress enough how much a standard
On 1 December 2016 at 19:45, Brooks Harris wrote:
> As I read it I think Google's intention is to publish their method and
> algorithm in the hopes others may follow it. It would be better if everybody
> did it the same way, but it will remain to be seen if others will choose to
> follow the examp
More details on the developer site:
https://developers.google.com/time/
Notably this page:
https://developers.google.com/time/smear
which include "Our proposed standard smear" - "We would like to
propose to the community, as the best practice for leap seconds in the
future, a 24-hour linear smear
On 28 September 2016 at 14:39, Tony Finch wrote:
> Steve Summit wrote:
>> Me, I'd very much rather *not* add this sort of thing to (say)
>> NTP, because NTP doesn't have a problem with leap seconds.
This does seem true - hacking ntp feels like the wrong solution.
> Except that every leap second
On 28 September 2016 at 12:35, Martin Burnicki
wrote:
> I think in general we need to distinguish if
>
> - smearing is done by a server, so that it hides the leap second from
> all its clients, and the clients don't even become aware of the leap second
>
> - smearing is done by a client, which rec
Leap second smearing is a way of taking UTC (with leap seconds) and
mapping it to a view of time that always has 86400 subdivisions per
day.
Tony Finch summarized five known approaches, which are all linear:
Amazon-12h +12h
Bloomberg -0 +2ks
Google-10h +10h
QTnet -"about 2 hours" +0
UTC
On 27 September 2016 at 14:40, Warner Losh wrote:
> Eliminating leap seconds would be a great way to unify all these approaches :)
> And it too is compatible with JTS.
JTS was written so it would be compatible if leap seconds were eliminated.
But, since they are NOT going to be eliminated now, i
On 27 September 2016 at 10:02, Tony Finch wrote:
> So, if everyone who is smearing is doing so piecewise-linear, it seems
> there is a great opportunity for them to get together and choose a
> consensus set of smear parameters.
>
> Amazon-12h +12h
> Bloomberg -0 +2ks
> Google-10h +10h
>
On 24 September 2016 at 21:52, Warner Losh wrote:
> I tend to view smearing as a repudiation of the concept of leap
> seconds. Let's do this kludge to keep the crazy world of nutty
> software written by people that don't know or don't care about leap
> seconds hobbling along at the expense of a bi
On 23 September 2016 at 19:35, Brooks Harris wrote:
> So, now there are at least 3 different smears in use by major providers to
> "hide" the Leap Second from downstream systems that might be upset by it.
As I've been saying for years, what we need (desperately) is a
standard for smearing, aka 86
On 22 July 2016 at 21:49, Steve Summit wrote:
> Stephen Colebourne:
>> My hope when I defined the Java time-scale was that eventually the
>> OS would provide it, or something very similar.
>
> Indeed. I've been exploring a reasonably straightforward
> scheme to hav
On 21 July 2016 at 23:49, Hal Murray wrote:
> Has anybody done any serious thinking about fixing the POSIX problem?
My hope when I defined the Java time-scale [1] was that eventually the
OS would provide it, or something very similar.
The basic observation that I have had over many years is that
> points to a fundamental flaw in the method we’ve chosen to keep atomic
> and solar time in sync?
>
> Warner
>
>> On May 19, 2015, at 2:10 AM, Stephen Colebourne wrote:
>>
>> A key point I've been making all along is that there needs to be an
>> internationa
A key point I've been making all along is that there needs to be an
internationally agreed standard for how to do the smoothing. In Java I
recommended UTC-SLS simply because it was at least a written up
approach. (My preference is for a linear change because there is less
chance of implementors get
On 12 March 2015 at 05:21, Steve Allen wrote:
> On Wed 2015-03-11T11:04:57 -0700, Tom Van Baak hath writ:
>> The entire purpose of UTC is to provide a single timescale for all
>> human-related activity.
>
> And UTC has failed miserably. POSIX says UTC has no leaps.
> Google says UTC has occasiona
Having taken part as an expert, I can say that the sessions were well
run and lots of data was presented to people. Where the sessions
differ from this list is that *everything* was considered (religion,
culture, astronomy), not the incredibly narrow technical arguments.
The general sentiment from
On 2 October 2014 00:00, Greg Hennessy wrote:
> On 10/01/2014 09:33 AM, Stephen Colebourne wrote:
>> We also need
>> - a clear smoothing/smearing standard, mapping from UTC (with leap
>> seconds) to smoothed-UTC (86400 secs per day, no leap seconds). This
>> could
On 1 October 2014 21:19, Hal Murray wrote:
> The leap offset data doesn't change very often. Why should it be distributed
> via NTP rather than with the time-zone database or something similar?
Because NTP already has support for it, and the data received by NTP
is then clear and complete.
Step
On 1 October 2014 13:02, Greg Hennessy wrote:
>> But the basic point still remains: If you have to sugar coat the actual
>> standard
>> with a fake standard to paper-over people’s inability to deal with the
>> actual
>> standard, this suggests that you have the wrong actual standard.
>
> I would a
On 30 September 2014 11:43, Tony Finch wrote:
> Stephen Colebourne wrote:
>>
>> I can safely say from my experience there, that if leap seconds are
>> abolished it will not be with the British peoples approval.
>
> I got the impression from the emphasis on non
That Matsakis document includes reference to the UK public dialogue. I
took part in that dialogue at one point as an "expert" on the topic.
The people (regular members of the public, randomly selected) involved
were taught what leap seconds were, and given opinions on whether they
should stay or go
On 19 January 2014 15:34, Daniel R. Tobias wrote:
> On 18 Jan 2014 at 19:51, Warner Losh wrote:
>
>> Of course, the 6 month window does make it impossible to compute a time_t
>> for a known
>> interval into the future that's longer than 6 months away...
>
> What are the applications that actually
On 19 August 2013 22:00, Warner Losh wrote:
> On Aug 18, 2013, at 3:29 AM, Stephen Colebourne wrote:
> Making things not match reality because users don't expect it either means
> that we've defined reality wrong ... or it means that you are being too
> clever.
Or sim
On 27 January 2012 13:58, Clive D.W. Feather wrote:
> Stephen Colebourne said:
>>> Oh? When is a month from Monday coming? What day is 4 months after the last
>>> day of next month? What about the antepenultimate day of next month?
>>> Explain your working in eac
On 27 January 2012 10:50, Clive D.W. Feather wrote:
> Stephen Colebourne said:
>> Interestingly, in JSR-310 I may end up representing a date as a packed
>> form of day-of-month (5 bits) and epoch-months (59 bits). Month
>> calculations are then easy.
>
> Oh? When is
On 27 January 2012 00:42, Hal Murray wrote:
> I think the key idea is that there are several units of time and things like
> leap seconds, time zones, and leap years make conversion between them far
> from simple.
>
> We want to work with time in units of:
> SI seconds
> Days
> Years
> kilo- a
On 23 January 2012 08:05, Poul-Henning Kamp wrote:
> You can always compare them ("is date1 before, the same or after date2")
> but you cannot subtract them and get a precise time-difference, if they
> span a potential leap-second application.
>
> One obvious hack is to add a "double *error" argum
On 20 January 2012 16:31, Poul-Henning Kamp wrote:
> >There is an IEEE spec for a large decimal number, which would be
> >preferable. Or a 96/128 bit integer.
>
> Only, it is not implemented anywhere, binary128 is.
Fine, but I'm very unenthused about floating point numbers in general.
I'm not sur
On 20 January 2012 23:51, Ian Batten wrote:
> >
> > (I would note that the implications of this approach appear to mean
> > that the +01:00 of Paris today, would eventually become +02:00, then
> > +03:00 and so on to +infinity. A fairly written document would note
> > that as being the case and i
On 20 January 2012 16:25, Tony Finch wrote:
> Stephen Colebourne wrote:
>>
>> Some have suggested that leap seconds could be absorbed as a "permanent
>> offset change". One of the proposals that should be written up is how that
>> would work.
>
> What
On 20 January 2012 15:08, Steve Allen wrote:
> On 2012 Jan 20, at 06:49, Stephen Colebourne wrote:
>> Some have suggested that leap seconds could be absorbed as a
>> "permanent offset change". One of the proposals that should be
>> written up is how that wo
On 20 January 2012 11:29, Poul-Henning Kamp wrote:
> With the leap-seconds still unresolved, it is time that we get real about
> time in the computer business.
True. I'm attempting to work out something better in Java at
ThreeTen/JSR-310. Co-ordination may be needed here.
> How anybody could get
On 20 January 2012 14:31, Daniel R. Tobias wrote:
> On 20 Jan 2012 at 17:26, Mark Calabretta wrote:
>
> > If UTC is discontinuous in any sense then so must the Gregorian
> > calendar be, with a "discontinuity" 86400 times greater on Feb/29.
>
> You don't even have to wait for a leap year for a no
On 19 January 2012 22:38, Warner Losh wrote:
> On Jan 19, 2012, at 10:57 AM, Stephen Colebourne wrote:
> > Consider it an opportunity to find consensus.
>
> That is unlikely if people believe it is axiomatic that time is
> fundamentally "time of day" and not &q
Consider it an opportunity to find consensus.
Stephen
On 19 January 2012 17:24, Rob Seaman wrote:
> So more Bush v Gore than Dewey beats Truman.
>
> ___
> LEAPSECS mailing list
> LEAPSECS@leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leap
On 18 January 2012 08:28, Poul-Henning Kamp wrote:
> Which part of "Coordinated" did you not understand in UTC ?
>
> UTC's semantics is "the timescale we agree to coordinate on", its
> relationship to the heavens above was merely a convenient matter
> of implementation.
>
Well I've always interp
It would seem that the meeting will be a clique. It seems to me that
getting new perspectives would have been more useful.
Stephen
On 4 October 2011 13:51, Zefram wrote:
> I wrote:
>>I have not had a response yet. I was just thinking about chasing it.
>
> Now chased it, got rejected. Allegedly
Not sure if anyone here got an invite to the UK Royal Society meeting.
I got rejected :-(
Stephen
On 11 July 2011 15:06, Rob Seaman wrote:
> Try: kavli.eve...@royalsociety.org
>
> If this works, let them know about the typo.
>
> Rob
> --
>
> On Jul 11, 2011, at 6:30 AM, Zefram wrote:
>
>> Steve
On 24 September 2011 06:59, mike cook wrote:
> I do think "day" should be defined as the synodic day, as that is what
> humans without clocks experience. That it varies in length is of no real
> consequence. As has probably been expressed elsewhere, the controversy over
> the definition of UTC, a
On 20 September 2011 17:04, Ian Batten wrote:
> Yes, indeed, if we allowed leap seconds to build up at the current rate,
> there would be an issue with an additional hour being required in the range
> of timezones in approximately five and a half thousand years' time (one leap
> second per eigh
On 20 September 2011 13:51, Daniel R. Tobias wrote:
>> You wouldn't be leaping UTC, you'd be leaping civil time. We're
>> used to that.
> Though we're not used to any local civil times being over 24 hours
> removed from UTC, which would happen eventually after a few millennia
> of UTC being uncou
I think a mechanism to map solar day linked UTC with leaps to an 86400
'sec' day (which is what most people believe to be the case) to be the
essential element that the original UTC authors missed. SLS seems a
reasonable and simple approach. My preferred change would be 3 year
leap sec notice, a na
Update including some comments sent earlier, and new entries on UTC
and local-time:
A star is used for a new or amended line.
General:
- these points of consensus exist to aid the understanding of leap
seconds not time in general
- the terms seconds, minutes, hours and days are overloaded
- relat
OK, so we've got a little bogged down in redefining what appear to be
well defined things, and whether a list like this should define things
anyway. I'll give it one more go, but sadly I don't have the "patience
of Job" if others don't also want consensus.
Remember, I'm not an expert to the same d
On 2 February 2011 18:13, Warner Losh wrote:
>> - an SI-based-minute is formed from exactly 60 SI-seconds
>> - an SI-based-hour is formed from exactly 60 SI-based-minutes and thus
>> exactly 3600 SI-seconds
>> - an SI-based-day is formed from exactly 24 SI-based-hours and thus
>> exactly 86400 SI-
On 2 February 2011 17:48, Steve Allen wrote:
> On Wed 2011-02-02T16:47:22 +0000, Stephen Colebourne hath writ:
>> - the SI-second is a standardised unit of measurement
>
> which is a conventional construct that is valid in a particular
> reference frame. If I build a perfect
Statements so far - disgree or add please (in particular something on
UT1/UT/etc as I will only get it wrong...):
General:
- the terms seconds, minutes, hours and days are overloaded, thus
pedantic and explicit terms are used here
SI
- the SI-second is a standardised unit of measurement
- the SI-
On 2 February 2011 15:33, Finkleman, Dave wrote:
> I suggest that the terms second, minute, hour, day, and month stated
> without qualification have "normative" status: the SI second, 60 SI
> seconds, 3600 SI seconds, 86,400 SI seconds, and Gregorian calendar
> numbers of days expressed as 86,400
On 2 February 2011 13:47, Daniel R. Tobias wrote:
> On 2 Feb 2011 at 8:32, Gerard Ashton wrote:
>
>> - the SI second is part of a coherent system of units and redefinition
>> of the second would
>> disturb the definition of most other units
>
> You could have multiple types of seconds, like you
On 2 February 2011 12:20, Tony Finch wrote:
> On Wed, 2 Feb 2011, Stephen Colebourne wrote:
>
>> - the solar-day is a commonly used unit of measurement
>
> Is it? I would agree that some kind of day is a commonly used unit of
> measurment, but I am not sure it's t
This list is good at disagreeing, but given the brainpower here,
perhaps some consensus building might be good? I'll try one approach,
and see what happens.
The concept here is to initially create a list of relevant statements
that *everyone* agrees with and no-one disagrees with. ie. remove
opini
On 1 February 2011 10:09, Poul-Henning Kamp wrote:
> A: Ehh, we sort of don't know how long a year is...
Poul, this is not true for JSR-310. A year is 365-366 days long. A day
is a fundamental unit. Thus we know exactly how long each are.
Taking a "second is the most important" viewpoint
On 1 February 2011 05:12, Mark Calabretta wrote:
>>It is also a central problem of time_t: how do you map this
>>non-uniform-radix notation onto a uniform count that must always satisfy
>>properties that explicitly mandate a uniform-radix.
>
> Vide the mapping of calendar date to Julian Date.
>
>
On 1 February 2011 06:45, Rob Seaman wrote:
> Successful programming environments model the behavior of the real world, not
> artificial constructs.
>
> Perhaps some progress could be made on the "predictable leap second
> scheduling" front? How would Java (or any software systems) gracefully
On 31 January 2011 19:57, Steve Allen wrote:
> In that is the nugget of how leap seconds are no different
> announcements that the daylight/summer time zones transition will
> happen at some date other than the previous schedule.
> (e.g., due to some sports event like the 2000 Olypmics and the 200
On 31 January 2011 15:59, Poul-Henning Kamp wrote:
> In message <12988684-b911-481b-b557-90e55cd73...@noao.edu>, Rob Seaman writes:
>>On Jan 31, 2011, at 1:07 AM, Poul-Henning Kamp wrote:
>
>>Is there really a requirement to render the concept of "universal
>>time" meaningless? Or is UTC merely c
On 31 January 2011 12:48, Tony Finch wrote:
> On Sat, 29 Jan 2011, Stephen Colebourne wrote:
>>
>> Thus, no matter what, the Sun must peak at midday and it be night at
>> midnight, with adjustments to ensure that based on time-zones. Since
>> stopping leap seconds brea
On 29 January 2011 23:36, Tom Van Baak wrote:
>> smoothing for that. (As I've said before, stopping leap seconds now
>> isn't helpful as it adds yet another mapping/complication, rather than
>> removing one)
>
> This I don't understand. As far as UTC is concerned, isn't the
> proposal to stop leap
On 30 January 2011 01:54, Steve Allen wrote:
> On 2011 Jan 29, at 17:34, Steve Allen wrote:
>> So I caution that JSR-310 is really creating a new time scale which
>> cannot be extrapolated into the past and which will only cause
>> confusion by claiming the name TAI when it cannot be TAI.
>
> and
On 29 January 2011 15:20, Tom Van Baak wrote:
>>> Your java class going to provide the true TAI, the true UTC,
>>> and the a user-friendly (smoothed, non leap second) version
>>> of UTC, right? If so, what name do you plan to use for that
>>> latter time scale? Some OS's use words like "system tim
On 29 January 2011 15:06, Gerard Ashton wrote:
> I suggest the following replacement for parts of the the Instant
> description. I offer the replacement because the wording of
> UTC-SLS clearly only applies after 1 January 1972, and that
> scale should be regarded as undefined prior to that date.
On 29 January 2011 17:35, Steve Allen wrote:
> On 2011 Jan 29, at 09:23, Warner Losh wrote:
>> A second minor point: TAI does not exist before this point. Proleptic TAI
>> is used, but more often TT is used for epochs prior to the present. I'd
>> just note here that a proleptic TAI is used for
This is the Javadoc of the UTCInstant class:
This implements leap seconds.
Please use this thread to discuss flaws in the documentation.
* An instantaneous point on the time-line measured in the UTC time-scale,
* handling leap seconds.
*
* Most of the Time Framework for Java works on the ass
This is the Javadoc of the TAIInstant class:
Please use this thread to discuss flaws in the Javadoc.
* An instantaneous point on the time-line measured in the TAI time-scale.
*
* Most of the Time Framework for Java works on the assumption that
the time-line is
* simple, there are no leap-se
This is the Javadoc for Instant, the most widely used class. It has
86400 "seconds" per day as most users want and expect.
Please use this thread for any feedback on this Javadoc, with any
recommended wording changes.
Please do not use this thread to discuss the rights and wrongs of
UTC-SLS or lea
On 29 January 2011 08:43, Tom Van Baak wrote:
>> If this happens, I therefore think that there may end up being two
>> versions of "UTC" in common use, which would be a far worse situation
>> than today.
>
> Your java class going to provide the true TAI, the true UTC,
> and the a user-friendly (sm
On 29 January 2011 02:02, Michael Sokolov wrote:
>> Thus my conversion is based around the primary importance of the day,
>> and its subdivisions of hour, minute and second making a fixed 86400
>> pattern.
>
> For the record, I agree with Stephen 100%. I choose to live my life on
> a rubber times
On 28 January 2011 23:58, Rob Seaman wrote:
> - The length-of-day on Earth has never been 86400 SI seconds long.
>
> - There are two different kinds of timekeeping.
>
> - It is the attempt to pretend otherwise that is causing the friction.
This isn't primarily my discussion,
On 28 January 2011 22:09, Keith Winstein wrote:
> Aside from others' concerns, I am a little worried about the nonfunctional
> nature of your API. The user might appreciate documentation about which
> expressions may vary across calls to registerSystemLeapSecond(), and which
> member functions are
On 28 January 2011 21:01, Steve Allen wrote:
> Taking that one step further, there are many UTCs, but there is only
> one TAI, and it is defined by the BIPM.
>
> Does the BIPM approve of the use of the name TAI for the concept which
> is specified by JSR-310?
>
> If not, how do you justify redefin
On 28 January 2011 20:42, Tom Van Baak wrote:
> Second question -- I assume your design of the new java class
> needs to address two different audiences; one are the 8 million
> developers but the other are the several dozen (?) implementers
> of the class on their own particular host OS or hardwa
On 28 January 2011 20:42, Tom Van Baak wrote:
>> As I said before, having looked at the subject, I now strongly believe
>> that any alteration to the current scheme of occasional leap-seconds
>> would be a serious mistake with large consequences.
>
> Can you explain the above comment a little more
On 28 January 2011 18:34, Steve Allen wrote:
> On Fri 2011-01-28T18:03:07 +0000, Stephen Colebourne hath writ:
>> JSR-310 addresses the definition of 1970-01-01Z (by defining the
>> TAI-UTC gap as fixed at 10 seconds prior to 1972.
>
> This is pointless silliness. This is
On 28 January 2011 17:15, Tom Van Baak wrote:
>> @Warner, UTC-SLS is simply a clearly written way to reconcile UTC to
>> practical computing/business. I wish it was a recognised standard, but
>> it isn't. That places me in the position of making it a de facto
>> standard unless I receive a suitabl
On 28 January 2011 16:17, Steve Allen wrote:
> On Fri 2011-01-28T08:55:34 -0700, Warner Losh hath writ:
>> The larger point is that nobody implements this in the real world.
>> UTC-SLS is largely just a paper standard that the vast majority of
>> people completely ignore. It seems unwise to code
On 28 January 2011 05:33, Tom Van Baak wrote:
> There are many forms of "SLS"; from those that spread the
> leap across one second, or two seconds, or 30 seconds or
> a minute, or an hour, or a day. Spread it across a year (or
> however long it's been since the last leap second) and you
> have UT1
round leap seconds - they want something in line
with their conceptual model of time.
"
Feedback welcome.
Stephen Colebourne
Project lead ThreeTen
Co-spec lead JSR-310
https://sourceforge.net/apps/mediawiki/threeten/index.php?title=ThreeTen
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
79 matches
Mail list logo
