Menu
▾
▴
Re: [Joda-interest] More on TAI/UTC
|
From: Brian S O'N. <bro...@ea...> - 2003-08-15 05:28:29
|
This is a followup to my previous post. Joda is using neither TAI nor UTC. From what I gather: 1958-01-01T00:00:00 TAI == 1958-01-01T00:00:00 UTC (proleptic, UTC not created until 1972) 1970-01-01T00:00:04.213 TAI == 1970-01-01T00:00:00 UTC 1972-01-01T00:00:10 TAI == 1972-01-01T00:00:00 UTC 1999-01-01T00:00:32 TAI == 1999-01-01T00:00:00 UTC 2001-09-09T01:47:12 TAI == 2001-09-09T01:46:40 UTC So if System.currentTimeMillis() returns 1,000,000,000,000 (2001-09-09T01:46:40 UTC), this represents the number of UTC milliseconds that have elapsed since 1970 UTC. UTC milliseconds are on average longer than SI milliseconds. The actual number of SI milliseconds that have elapsed is 32000 - 4213 = 27787 milliseconds more. After constructing a DateTime with the system time, the adjustment must be made so that the internal TAI milliseconds is 1,000,000,027,787. Okay, so far so good, but what happens when someone creates a DateTime from just a millis value? Do we assume that the millis value is UTC or TAI? If TAI, then the internal TAI millis value can easily be moved between Joda time classes. However, if I take a millis value from some other Java API, I must make sure that I specify UTC in order for the proper conversion to be applied. If the millis constructor remains as always accepting UTC millis, then passing millis between Joda classes becomes a cumbersome. Should there exist two getMillis methods? getMillisUTC, getMillisTAI? Mixing up the TAI/UTC zone on the millis would be an easy mistake to make and overlook. This was why I was suggesting earlier that the epoch we should use is 1958-01-01. If you make the mistake, it cannot be overlooked, for you are more than a few seconds off, you're 12 years off! I'm going in circles trying to come up with a solution other than moving the epoch. We might just have to give up and leave things as they are. Even if leap seconds were fully supported, and TAI was used internally, we can only acurately represent dates from 1958 to now. We have no leap second data before 1958, and none for the future. I guess the best solution then is to document that the UTC zone is really an approximate, where the length of a UTC second is assumed to be the same as an SI second. A TAI time zone can be created that applies reverse leap seconds to derive TAI from UTC. There's no rush to go forward with implementing this, but at least we'll have an archived discussion of the issue. ----- Original Message ----- From: "Stephen Colebourne" <sco...@jo...> To: "Joda Interest" <jod...@li...> Sent: Thursday, August 14, 2003 01:27 P Subject: Re: [Joda-interest] More on TAI/UTC > Currently, Joda uses TAI, although it calls it UTC. This seems sensible > because > - it is compatable with Java > - it is the fastest for calculations > > The TAI ms definition requires changes to comments to begin with. The only > clash is on the asUTC() method on Chronology. This would need to be asTAI(). > > A GJUTCChronology could then be written to return the fields using leap > second adjusted UTC. Would this work OK? > > Stephen > > ----- Original Message ----- > From: "ONeill, Brian" <Bri...@di...> > I've not used C#, but from looking at the DateTime APIs, it looks to me > that the internal representation is completely hidden. There is a > function that converts "filetime" to a DateTime, and filetimes have an > epoch of 1601-01-01. > > Before Joda I had heard of neither UTC nor TAI. I thought time zones > were referenced from GMT. The reason I'm bringing this up now is that I > recently read this > http://www.guardian.co.uk/uk_news/story/0,3604,985020,00.html which > reminded me of all the stuff I learned while implementing in time zones. > > Other libraries do implement leap seconds, like glibc, except it's a > mode that must be defined when compiled. The Olson database defines the > leap seconds used by glibc. I'd like Joda to be as capable as glibc when > representing times. > > Supporting leap seconds poses a few problems. The first being the speed > of internal calculations. If they are all against true UTC, then leap > seconds need to be accounted for all the time. Certain areas of Joda are > optimized for speed by switching to from local to UTC and back. TAI has > the advantage that it has no special adjustments, and thus is the > fastest when performing calculations. > > I would like to support leap seconds and still be similar to existing > Java times, but I'm still trying to wrap my head around the problem. > > -----Original Message----- > From: Stephen Colebourne [mailto:sco...@jo...] > Sent: Tuesday, August 05, 2003 02:13 P > To: Joda Interest > Subject: Re: [Joda-interest] More on TAI/UTC > > > I'm don't mind us renaming our definitions to refer to TAI, not UTC. But > going beyond that seems to be pushing at a boundary that doesn't need > pushing. > > 1970, may not be a meaningful epoch in calculation terms, but then > neither is 1958. I think C# also uses 1970, but I can't remember for > sure. > > It is meaningful to users however. The getMillis() methods (and any > others that take in millis) must be 1970 based. Anything else would be > really confusing. One thing about open source is that other developers > can arrive and want to add stuff in, or debug the code, or just read it. > Explaining why we changed to 1970 would be very difficult. And > System.curentTimeMillis() is definitely an important call to compare > against. > > Another point is that I hadn't heard of TAI. I had heard of UTC before > starting Joda. And there are certainly views around on the internet that > the whole leap seconds concept is a Bad Idea. > > > I'm not sure where you are coming from on this. There is no user use > case to base time on TAI that I can think of. It will cause unexpected > problems for users when they do millis + 60000 and don't get exactly one > minute later. Leap seconds are just plain non-mainstream. (OK, maybe > users shouldn't mess around with raw millis values, but they do and will > continue to do so. To break this breaks the whole library IMO) > > You mention that you think that these classes could be a model to follow > on other languages. Well maybe, if we succeed they will. But they will > always have to adapt to the local language. Only in a new programming > language could a different epoch be chosen. And even then I would argue > against leap seconds. > > Stephen > > ----- Original Message ----- > From: "ONeill, Brian" <Bri...@di...> > To: "Stephen Colebourne" <sco...@jo...>; "Joda Interest" > <jod...@li...> > Sent: Tuesday, August 05, 2003 9:44 PM > Subject: RE: [Joda-interest] More on TAI/UTC > > > Technically, we're not using UTC, but TAI. UTC implies leap seconds, and > if Joda doesn't support leap seconds, then we can't say UTC. It is > recommended that libraries which don't truly implement UTC say they > offer TAI instead. > > As far as epochs are concerned, I think the 1970 Java convention from > Unix makes no sense. If a different epoch was chosen, few users whould > know or care. The nice thing about 1958-01-01 is that it is a meaningful > epoch. As far as TAI is concerned, this is when time truly began. > > At first I thought that supporting a different epoch would cause > problems, but then I realized that the DateTime class exists so that the > data is hidden from view. The constructors and methods perform all the > conversions, so mixing millis values should never happen. If they do, it > will be glaringly obvious. > > I know many developers that aren't even aware of the > System.currentTimeMillis call and always call new Date().getTime() > instead. They're not manipulating the millis values, they're just using > it as a timestamp. They are also unaware of the millis epoch since they > are perfectly happy letting the Date class manage that. When serializing > dates, most developers I have met don't even consider saving just the > millis value. It's not as portable (or readable) as an ISO format. > > Too often people go off and write little datetime manipulation classes > because what they are currently using is wrong or incomplete. These new > implementations are also wrong and incomplete. People also create new > libraries based on broken ones. This is how java.util.Date came into > existence. > > I think this is an opportunity to raise the bar and produce a set of > datetime classes that is as correct and as efficient as possible. It > should also be a model for others to follow, and the time libraries > should eventually make their way into other languages. > > > > -----Original Message----- > From: Stephen Colebourne [mailto:sco...@jo...] > Sent: Tuesday, August 05, 2003 01:18 P > To: Joda Interest > Subject: Re: [Joda-interest] More on TAI/UTC > > > I can't say that I'm terribly enthusiastic about this. > > The Java convention of 1970 is very well established in peoples minds. > Changing it would mean that converting between Joda and Java dates would > be very tricky and easy to get wrong. ie. users will expect a > milliseconds long to be the same everywhere. > > I'm also dubious about the need for leap seconds. They are not widely > used, or even known about. Really they are only of interest to > astronomers. Or do you have a particular use case in mind? > > I would be much happier to see this added as a separate Chronology that > people must explicitly choose. (And IMHO, 99% of the people won't). Now > that means keeping the current 1970 no leap second definition for a > millisecond long. > > Simple conversion to and from Java dates is (unfortunately) a must. Does > this make sense? > > Stephen > > > ----- Original Message ----- > From: "Brian S O'Neill" <bro...@ea...> > To: "Joda Interest" <jod...@li...> > Sent: Tuesday, August 05, 2003 6:01 AM > Subject: [Joda-interest] More on TAI/UTC > > > If we decided that Joda time is based on TAI instead of UTC, then users > may be confused when they put in a millis from 1970 value and see a time > that's 32 seconds off. Or they might not notice at first, but scratch > their heads later. > > If based on TAI, then I feel the epoch should move from > 1970-01-01T00:00:10 TAI to 1958-01-01T00:00:00 TAI, the origin of TAI. > > If a user plugs in a millis from 1970 value, they'll see much more than > 32 seconds of error, immediately alerting them that they did something > wrong. > > Of course, this change is quite drastic, but we are not yet a 0.9 > version, so its much easier to change sooner than later. > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 > /01 > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 > /01 > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Joda-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-interest |