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 2011 Jan 29, at 00:27, Stephen Colebourne 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.
But there already are two versions of UTC in use.
The one as defined by TF.460 and implemen
In message , Step
hen Colebourne writes:
>It is my opinion, coming from an open source background,
>body currently defining leap seconds stops doing so with less than
>100% consensus, then the leap second defining process would be forked.
It is my experience, based on almost 25 years of open sou
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.
Stephen
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
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
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
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 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
On 1/29/2011 3:27 AM, Stephen Colebourne wrote, in part:
It is my opinion, coming from an open source background, that if the
body currently defining leap seconds stops doing so with less than
100% consensus, then the leap second defining process would be forked.
Some other person/body/open sour
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.
This is the Javadoc for Instant, the most widely used
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 time"
or "gmtime".
I call it the "UTC-SLS" time-scale. See new
First, two time scales, one civil and one technical, seems like a very good
idea. Any correlation between them need not be scientifically precise. There
is much literature on countries and religions with two or more calendars, some
for ecclesiastical and some for commercial endeavors. Why no
On 01/29/2011 02:00, Stephen Colebourne wrote:
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 th
On 28 Jan 2011 at 23:59, Warner Losh wrote:
> Just for the record. I have no minions, armed or otherwise.
Do you have a minyan (defined as ten Jewish males, needed to begin
prayer in Orthodox Jewish tradition)?
--
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips:
On 29 Jan 2011 at 2:02, Michael Sokolov wrote:
> I choose to live my life on a rubber timescale similar to UTC-SLS,
> and I am prepared to use deadly firepower to defend my right to
> live my life on this timescale. If PHK or Warner Losh or their
> armed minions (aka local sheriffs enforcing laws
Warner Losh wrote:
> Just for the record. I have no minions, armed or otherwise.
Yes you do: they are called sheriffs/cops/etc, and are unfortunately
present in almost every country on Earth with the possible exception of
small countries like the Principality of Sealand which to my knowledge
do
On 01/29/2011 02:00, Stephen Colebourne wrote:
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 th
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 dates prior to the 1958 epoch.
The agreement to s
Ken, John Seago, and I delivered a paper to the AAS last August that includes
many of the thoughts in this thread. In particular, we suggest that the ITU
should not own UTC. We also provide concrete alternatives that we are pursuing
at least without failure (can't really say "success."). Mike
Daniel R. Tobias wrote:
> Is there actually anybody on any side of the great time scale debates
> who advocates sending government agents to people's homes to ensure
> that all their clocks are set to the "correct" standard, possibly
> arresting my mom [...]
Whether they mean it or not, that
On 2011-01-28 18:34, Gerard Ashton asked:
Windows and Unix have general reputations of not doing it right; does
anyone know of a hardware/operating system combination that handles leap
seconds correctly? If so, does it have a defined approach to providing a
quasi-UTC that hides leap secon
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
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 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
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 seconds effectively the same as IERS
just not sending out
I suggest that UT, as a concept, can be extended as far back as the
location of Greenwich
can be discerned, even if it was known by some other name. I suggest
that encompass all
recorded history. Since UT1 was originally defined as a function of
sidereal time and the function was created by Sim
On 2011 Jan 29, at 14:21, Stephen Colebourne wrote:
> What JSR-310 needs is a single time-scale that has a single
> incrementing number of fixed size units (SI seconds) with no other
> interpretations (such as what a day is). I believe that TAI best meets
> that definition today, and thus is the ch
On 2011 Jan 29, at 14:31, Stephen Colebourne wrote:
> Thanks for the thoughts. I can see where you are driving at, but since
> UT/UT1/UT2 are not well-defined in the far past AFAIK, then the
> definition below isn;t ideal either. I agree that something needs to
> change though.
The issue of the pa
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 if the BIPM follows through with the suggestion that t
On 2011 Jan 29, at 09:39, Finkleman, Dave wrote:
> In particular, we suggest that the ITU should not own UTC.
The adjective "co-ordinated" in conjunction with Universal Time
occurs in the proceedings of the IAU general assembly of 1961.
The books by Audoin & Guinot and by McCarthy & Seidelmann bot
30 matches
Mail list logo
