OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

unitsml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: FW: threeten-develop Digest, Vol 6, Issue 12


Title: threeten-develop Digest, Vol 6, Issue 12
Referring back to our discussion on leapseconds a meeting or two ago, here's an interesting use case and some links on issues relating to UTC.  Thought you guys might find this interesting.
 
Karen Legrand


From: threeten-develop-request@lists.sourceforge.net [mailto:threeten-develop-request@lists.sourceforge.net]
Sent: Mon 10/17/2011 6:50 AM
To: threeten-develop@lists.sourceforge.net
Subject: threeten-develop Digest, Vol 6, Issue 12

Send threeten-develop mailing list submissions to
        threeten-develop@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.sourceforge.net/lists/listinfo/threeten-develop
or, via email, send a message with subject or body 'help' to
        threeten-develop-request@lists.sourceforge.net

You can reach the person managing the list at
        threeten-develop-owner@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of threeten-develop digest..."


Today's Topics:

   1. Re: UTCDateTime (Mike Douglass)
   2. Re: UTCDateTime (Brian Harris)
   3. Re: UTCDateTime (Stephen Colebourne)
   4. Re: UTCDateTime (Stephen Colebourne)
   5. Re: UTCDateTime (Brian Harris)


----------------------------------------------------------------------

Message: 1
Date: Sun, 16 Oct 2011 21:01:21 -0400
From: Mike Douglass <douglm@rpi.edu>
Subject: Re: [threeten-develop] UTCDateTime
To: threeten-develop@lists.sourceforge.net
Message-ID: <4E9B7E61.3020608@rpi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Just about every astronomer...

It turns out that software which drives telescopes only works to within
a second or so of a deviation from the current UTC. Leapseconds help
keep that software working correctly.

There's also at least one space agency that refuses to launch near a
leap second transition.

http://futureofutc.org/

provides more on the possible demise of the leap second and who 'owns' UTC

as does
http://iopscience.iop.org/0026-1394/48/4/S08/pdf/0026-1394_48_4_S08.pdf

On 10/16/2011 08:40 PM, Stephen Colebourne wrote:
>> I wasn't considering UTCInstant a datetime type because it doesn't have
>> >  "getMinuteOfHour", for example. Do you see 310 ever offering a type with
>> >  "getMinuteOfHour" that supports leap seconds? If not, why not?
> I don't believe enough people understand or care about leap seconds to
> justify that.

--

Mike Douglass                           douglm@rpi.edu
Senior Systems Programmer
Communication&  Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180




------------------------------

Message: 2
Date: Sun, 16 Oct 2011 21:10:45 -0400
From: Brian Harris <brianfromoregon@gmail.com>
Subject: Re: [threeten-develop] UTCDateTime
To: threeten-develop@lists.sourceforge.net
Message-ID:
        <CAFtUM9amom=NCMq+9u5n=NJPgPAsF3pteEAtSsmHLUeyQN_CxQ@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

This DAL wants to store/restore UTC datetimes. The DB column would be named
"utcdatetime", By mandating UTC datetimes I don't need to store the zone
separately. This is a common approach for storing datetimes.

This DAL interface should use a UTCDateTime (ZeroOffsetDateTime, as you
called it), but that type doesn't exist. I'm proposing we add it to 310.

On Sun, Oct 16, 2011 at 8:40 PM, Stephen Colebourne <scolebourne@joda.org>wrote:

> On 17 October 2011 01:08, Brian Harris <brianfromoregon@gmail.com> wrote:
> > My DAL example shows why ZonedDateTime isn't good enough. I'm
> recommending
> > adding a type for this use case, do you agree 310 would benefit from this
> > new type?
>
> Your DAL example shows an implementation of an interface that is
> failing to correctly implement. Any database code like that DAL must
> store both the instant and the zone-id - probably using two columns in
> SQL.


> >> > Do you have a datetime type today that includes leap seconds? Do you
> >> > plan to
> >> > support that?
> >> UTCInstant includes leap seconds.
> >
> > I wasn't considering UTCInstant a datetime type because it doesn't have
> > "getMinuteOfHour", for example. Do you see 310 ever offering a type with
> > "getMinuteOfHour" that supports leap seconds? If not, why not?
>
> I don't believe enough people understand or care about leap seconds to
> justify that.
>
> Stephen
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> threeten-develop mailing list
> threeten-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>
-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 3
Date: Mon, 17 Oct 2011 08:21:43 +0100
From: Stephen Colebourne <scolebourne@joda.org>
Subject: Re: [threeten-develop] UTCDateTime
To: threeten-develop@lists.sourceforge.net
Message-ID:
        <CACzrW9Bp0cdCXe=PgLvbqAFE8O707HrfOGXh2seWEYp5JV1RsA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

And I'm saying that type exists. Its Instant.

Stephen


On 17 October 2011 02:10, Brian Harris <brianfromoregon@gmail.com> wrote:
> This DAL wants to store/restore UTC datetimes. The DB column would be named
> "utcdatetime", By mandating UTC datetimes I don't need to store the zone
> separately. This is a common approach for storing datetimes.
> This DAL interface should use a UTCDateTime (ZeroOffsetDateTime, as you
> called it), but that type doesn't exist. I'm proposing we add it to 310.
> On Sun, Oct 16, 2011 at 8:40 PM, Stephen Colebourne <scolebourne@joda.org>
> wrote:
>>
>> On 17 October 2011 01:08, Brian Harris <brianfromoregon@gmail.com> wrote:
>> > My DAL example shows why ZonedDateTime isn't good enough. I'm
>> > recommending
>> > adding a type for this use case, do you agree 310 would benefit from
>> > this
>> > new type?
>>
>> Your DAL example shows an implementation of an interface that is
>> failing to correctly implement. Any database code like that DAL must
>> store both the instant and the zone-id - probably using two columns in
>> SQL.
>>
>> >> > Do you have a datetime type today that includes leap seconds? Do you
>> >> > plan to
>> >> > support that?
>> >> UTCInstant includes leap seconds.
>> >
>> > I wasn't considering UTCInstant a datetime type because it doesn't have
>> > "getMinuteOfHour", for example. Do you see 310 ever offering a type with
>> > "getMinuteOfHour" that supports leap seconds? If not, why not?
>>
>> I don't believe enough people understand or care about leap seconds to
>> justify that.
>>
>> Stephen
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2d-oct
>> _______________________________________________
>> threeten-develop mailing list
>> threeten-develop@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> threeten-develop mailing list
> threeten-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>
>



------------------------------

Message: 4
Date: Mon, 17 Oct 2011 08:24:38 +0100
From: Stephen Colebourne <scolebourne@joda.org>
Subject: Re: [threeten-develop] UTCDateTime
To: threeten-develop@lists.sourceforge.net
Message-ID:
        <CACzrW9CShaFDGopUDvs0KZ7_PjXu2Ls8+oHJgmXitdD3skLt5w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

I'm very aware of the plans to remove leap seconds. The reality is
that most developers are unaware of leap seconds and assume there are
86400 seconds in a day always, thus that is what the system models.
The API consequences of not doing that are very unpleasant. The
UTCInstant and TAIInstant classes exist for astronomers and others
that do care.

Stephen



On 17 October 2011 02:01, Mike Douglass <douglm@rpi.edu> wrote:
> Just about every astronomer...
>
> It turns out that software which drives telescopes only works to within
> a second or so of a deviation from the current UTC. Leapseconds help
> keep that software working correctly.
>
> There's also at least one space agency that refuses to launch near a
> leap second transition.
>
> http://futureofutc.org/
>
> provides more on the possible demise of the leap second and who 'owns' UTC
>
> as does
> http://iopscience.iop.org/0026-1394/48/4/S08/pdf/0026-1394_48_4_S08.pdf
>
> On 10/16/2011 08:40 PM, Stephen Colebourne wrote:
>>> I wasn't considering UTCInstant a datetime type because it doesn't have
>>> > ?"getMinuteOfHour", for example. Do you see 310 ever offering a type with
>>> > ?"getMinuteOfHour" that supports leap seconds? If not, why not?
>> I don't believe enough people understand or care about leap seconds to
>> justify that.
>
> --
>
> Mike Douglass ? ? ? ? ? ? ? ? ? ? ? ? ? douglm@rpi.edu
> Senior Systems Programmer
> Communication& ?Collaboration Technologies ? ? ?518 276 6780(voice) 2809
> (fax)
> Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> threeten-develop mailing list
> threeten-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>



------------------------------

Message: 5
Date: Mon, 17 Oct 2011 06:50:21 -0400
From: Brian Harris <brianfromoregon@gmail.com>
Subject: Re: [threeten-develop] UTCDateTime
To: threeten-develop@lists.sourceforge.net
Message-ID:
        <CAFtUM9bypxsmWk40kjMuzinMrJc=zyVYmzqoK5M+=nJu-Z1vww@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Instant doesn't have the convenient datetime methods like getMinuteOfHour
which is why I was pushing for a datetime type.

But your point is fair. If I want this type, I'll add it to my code base
separately.

On Mon, Oct 17, 2011 at 3:21 AM, Stephen Colebourne <scolebourne@joda.org>wrote:

> And I'm saying that type exists. Its Instant.
>
> Stephen
>
>
> On 17 October 2011 02:10, Brian Harris <brianfromoregon@gmail.com> wrote:
> > This DAL wants to store/restore UTC datetimes. The DB column would be
> named
> > "utcdatetime", By mandating UTC datetimes I don't need to store the zone
> > separately. This is a common approach for storing datetimes.
> > This DAL interface should use a UTCDateTime (ZeroOffsetDateTime, as you
> > called it), but that type doesn't exist. I'm proposing we add it to 310.
> > On Sun, Oct 16, 2011 at 8:40 PM, Stephen Colebourne <
> scolebourne@joda.org>
> > wrote:
> >>
> >> On 17 October 2011 01:08, Brian Harris <brianfromoregon@gmail.com>
> wrote:
> >> > My DAL example shows why ZonedDateTime isn't good enough. I'm
> >> > recommending
> >> > adding a type for this use case, do you agree 310 would benefit from
> >> > this
> >> > new type?
> >>
> >> Your DAL example shows an implementation of an interface that is
> >> failing to correctly implement. Any database code like that DAL must
> >> store both the instant and the zone-id - probably using two columns in
> >> SQL.
> >>
> >> >> > Do you have a datetime type today that includes leap seconds? Do
> you
> >> >> > plan to
> >> >> > support that?
> >> >> UTCInstant includes leap seconds.
> >> >
> >> > I wasn't considering UTCInstant a datetime type because it doesn't
> have
> >> > "getMinuteOfHour", for example. Do you see 310 ever offering a type
> with
> >> > "getMinuteOfHour" that supports leap seconds? If not, why not?
> >>
> >> I don't believe enough people understand or care about leap seconds to
> >> justify that.
> >>
> >> Stephen
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> All the data continuously generated in your IT infrastructure contains a
> >> definitive record of customers, application performance, security
> >> threats, fraudulent activity and more. Splunk takes this data and makes
> >> sense of it. Business sense. IT sense. Common sense.
> >> http://p.sf.net/sfu/splunk-d2d-oct
> >> _______________________________________________
> >> threeten-develop mailing list
> >> threeten-develop@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/threeten-develop
> >
> >
> >
> ------------------------------------------------------------------------------
> > All the data continuously generated in your IT infrastructure contains a
> > definitive record of customers, application performance, security
> > threats, fraudulent activity and more. Splunk takes this data and makes
> > sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2d-oct
> > _______________________________________________
> > threeten-develop mailing list
> > threeten-develop@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/threeten-develop
> >
> >
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> threeten-develop mailing list
> threeten-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>
-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

------------------------------

_______________________________________________
threeten-develop mailing list
threeten-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/threeten-develop


End of threeten-develop Digest, Vol 6, Issue 12
***********************************************



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]