From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2b151131f90050ab X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-28 18:41:39 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!cleanfeed.casema.net!leda.casema.net!isdnet!enst!enst.fr!not-for-mail From: "Steven Deller" Newsgroups: comp.lang.ada Subject: RE: Ada, calendar, and daylight savings Date: Sun, 28 Oct 2001 21:34:11 -0500 Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: avanie.enst.fr 1004323298 29448 137.194.161.2 (29 Oct 2001 02:41:38 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Mon, 29 Oct 2001 02:41:38 +0000 (UTC) To: Return-Path: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3BDC97CE.8070304@acm.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.6 Precedence: bulk X-Reply-To: List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , List-Archive: Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:15323 Date: 2001-10-28T21:34:11-05:00 Corey, Take a look at Posix_Calendar. It *looks* like Ada's package Ada.Calendar, with the following modification: 4.4.1.1 Description The type POSIX_Time shall be used to obtain times and dates from the system. Values of this type shall be independent of the current time zone in effect for the system, so that an arbitrary value of this type may be interpreted at a later date using information in the TZ environment variable (see 2.5.1). Essentially this means that Posix_Calendar is, like Ada.Real_Time.??, monotonically increasing. And unlike Ada's Calendar package, it does not try to mix in timezone information with "Time". Typically "Time" is UTC, but the option is left to a Posix compliant system to choose something else. When a timezone is layered over UTC, there is no difficulty with interpretation, EXCEPT when trying to specify a year/month/day/time that happens to be during the one period of the year when the same time occurs twice, i.e. in the fall when the clocks are turned back, the same year/month/day/time occurs twice so how can one specify unequivocally, which UTC is intended? So, is 28 Oct 2001 1:30am with EDT supposed to have a +4 or +5 offset added when converting to UTC? The simple answer is that it is always the first time, i.e. the +4 offset for EDT, that is added. One then has to add one hour to the time out from Time_Of if the input was intended to be the hour following the switch. That does mean that after S : Time := Clock ; T : Time ; Split (S, Year, Month, Day, Seconds ) ; T := Time_Of ( Year, Month, Day, Seconds) ; The values in T and S will not always be equal. Of course, since Time can have greater accuracy than Duration, it is always the case that T may not equal S. The answer to this is "Don't expect that identity from Calendar". Typically one works only in the underlying Time (which is unequivocal) and only uses a timezone for during output. Or possibly one uses timezone for input from the user, and then must ask the user to differentiate the time if it happens to be one with multiple interpretations in the timezone that is in effect. Better just to ask the user to input UTC and convert according to that timezone. Because Ada mixed in timezone information with Calendar (and hid the timezone), it is impossible to tell what is the real meaning of time, and how to convert it reasonably. The "Time" type in Ada.Calendar is fundamentally a poor design. The only reasonable use of Calendar in Ada is for inexact, convenient "match the wall clock" use. And even there it has some problems. For reasoning about time, one should use Ada.Real_Time. For timestamping, either create your own using a combination of Ada.Calendar and Ada.Real_Time, or use Posix_Calendar. Of course, using Ada.Real_Time is awkward at best, since it is very difficult to actually find out what a time span is (in printable units) without converting to Duration, and Duration typically loses the very accuracy one wanted from Ada.Real_Time in the first place. Sigh... Regards, Steve "Then, after a second or so, nothing continued to happen." Steven Deller Smooth Sailing LLC 410 757 6924 deller@smsail.com > -----Original Message----- > From: comp.lang.ada-admin@ada.eu.org > [mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Corey Minyard > Sent: Sunday, October 28, 2001 6:41 PM > To: comp.lang.ada@ada.eu.org > Subject: Ada, calendar, and daylight savings > > > I've been looking at calendar issues in Ada, I'm trying to write a > complete calendar package for Ada. I'm trying to understand how > daylight savings works in Ada.Calendar. > > An average day has 86_400 seconds (24 * 3600). However, the > day where > daylight savings time is activated would seem to have 82_800 > seconds (23 > * 3600) and the day where daylight savings time is > deactivated, as just > happened in the US, would seem to have 90_000 seconds (25 * 3600). > > I would seem to me that the seconds in the day would not be > dependent on > daylight savings, but would instead range 0 .. 90_000. Otherwise, > certain times cannot be represented properly in certain > circumstances. > For instance, if you do the following: > > with Ada.Text_IO; use Ada.Text_IO; > with Ada.Calendar; use Ada.Calendar; > > procedure T1 is > Time1 : Time; > Time2 : Time; > Year1 : Year_Number; > Month1 : Month_Number; > Day1 : Day_Number; > Seconds : Duration; > begin > Time1 := Time_Of(2001, 10, 28, 3600.0 * 1.5) + 3600.0; > Split(Time1, Year1, Month1, Day1, Seconds); > Time2 := Time_Of(Year1, Month1, Day1, Seconds); > if (Time1 = Time2) then > Put_Line("Times are equal"); > else > Put_Line("Times are unequal"); > end if; > end T1; > > The times will not be equal (at least on GNAT-3.12p in a US > timezone). > Is this the intent? If so, there is no easy way to tell the two > "1:30AM" times apart from each other, because the calendar > package gives > no way to tell if DST is active. I guess you could figure out of DST > might active on that day and add an hour to see if you get the same > "seconds" value back, but that's kind of a pain. I guess I'm used to > the Java calendar package, which is quite powerful and comples. The > whole date/time things is a big mess, anyway. > > Thanks for any insight on this. > > -Corey > > _______________________________________________ > comp.lang.ada mailing list > comp.lang.ada@ada.eu.org > http://ada.eu.org/mailman/listinfo/comp.lang.ada >