* Re: C date package [not found] <l0313030eb53d1408aee7@[144.205.16.58]> @ 2000-05-09 0:00 ` Geoff Bull 2000-05-09 0:00 ` Geoff Bull 0 siblings, 1 reply; 34+ messages in thread From: Geoff Bull @ 2000-05-09 0:00 UTC (permalink / raw) here are some calendar links: http://emr.cs.uiuc.edu/home/reingold/calendar-book/calendar-links.shtml Dale Stanbrough wrote: > i would disagree. In the same way that we use GMT as standard for time, we > should be able to come up with a time based system that underlies the > various views that are needed. > > After all, a date that is 30,000 days ago -is- 30,000 days ago, no matter > what calendar is used. > > 1752's interpretation could then be viewed by using a gregorian calendar > package, or a julian calendar package (i presume this is where the > difference is...). ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: C date package 2000-05-09 0:00 ` C date package Geoff Bull @ 2000-05-09 0:00 ` Geoff Bull 2000-05-09 0:00 ` Robert Dewar 0 siblings, 1 reply; 34+ messages in thread From: Geoff Bull @ 2000-05-09 0:00 UTC (permalink / raw) Geoff Bull wrote: > Dale Stanbrough wrote: > > i would disagree. In the same way that we use GMT as standard for time, Isn't GMT defunct? > > we should be able to come up with a time based system that underlies the > > various views that are needed. Sounds simple, just base time in the primary time standard: TAI (International Atomic Time). Ada.Real_Time is already based on TAI. And then you layer, Gregorian, Julian, Jewish or whatever calendar you want on top of that ? Trouble is people will start arguing about resolution and range. Do we try to cover needs of astronomers, real time programmer's and the rest of us with one time abstraction. The current Ada.Calendar is pretty weak - just reports an implementation defined time - local time on my system. > > > > After all, a date that is 30,000 days ago -is- 30,000 days ago, no matter > > what calendar is used. In a sense this isn't true. 30,000 rotations of the earth is /= 30,000 * 24 * 60 * 60 seconds. The problem with dealing with time and date is that you are mixing up two concepts: the lapse of a number of fixed size seconds (fixed by definition), the lapse of number of varying size days (in terms of number of seconds). ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: C date package 2000-05-09 0:00 ` Geoff Bull @ 2000-05-09 0:00 ` Robert Dewar 2000-05-10 0:00 ` Geoff Bull 0 siblings, 1 reply; 34+ messages in thread From: Robert Dewar @ 2000-05-09 0:00 UTC (permalink / raw) In article <39178DEA.FD2C20FA@research.canon.com.au>, Geoff Bull <geoff@research.canon.com.au> wrote: > The current Ada.Calendar is pretty weak - just reports an > implementation defined time - local time on my system. Well that seems pretty strong to me, given that the design point of the Ada.Calendar package is precisely to report the commonly used local time on your system. Almost any package is weak if you start expecting it to do things completely outside what it was designed for (for example I have found Ada.Numerics.Generic_Elementary_Functions virtually useless for doing computations on arbitrary precision arithmetic quantities). Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: C date package 2000-05-09 0:00 ` Robert Dewar @ 2000-05-10 0:00 ` Geoff Bull 2000-05-10 0:00 ` Robert Dewar 0 siblings, 1 reply; 34+ messages in thread From: Geoff Bull @ 2000-05-10 0:00 UTC (permalink / raw) Oops, I posted to comp.lang.ada by mistake! This was a thread on team-ada discussing which started with the "2038 bug". Robert Dewar wrote: > > In article <39178DEA.FD2C20FA@research.canon.com.au>, > Geoff Bull <geoff@research.canon.com.au> wrote: > > > The current Ada.Calendar is pretty weak - just reports an > > implementation defined time - local time on my system. > > Well that seems pretty strong to me, given that the design point > of the Ada.Calendar package is precisely to report the commonly > used local time on your system. > > Almost any package is weak if you start expecting it to do > things completely outside what it was designed for Fair enough, weak was probably the wrong word (maybe I should used "basic") - it doesn't even split out hours and minutes. And it would be reasonable to believe that anything in the Ada standard meets the design goals. But I don't even see where the RM says it reports local time, UTC UT1, TAI or whatever. Of course this is documented, as required, in the Gnat reference manual. 9.6 23.The time base associated with the type Time of package Calendar is implementation defined. 9.6 24.The functions Year, Month, Day, and Seconds return the corresponding values for a given value of the type Time, as appropriate to an implementation-defined timezone. So if I run two different Ada compilers on my system they are quite within their rights to report different times. A function that reported the offset from UTC, e.g., would be useful. I guess implementations that didn't know about timezones would have to be permitted to always return 0. It would be a bit much to ask for the weekday name when ther is no awareness of the current locale. Cheers Geoff ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: C date package 2000-05-10 0:00 ` Geoff Bull @ 2000-05-10 0:00 ` Robert Dewar 2000-05-10 0:00 ` Ken Garlington ` (2 more replies) 0 siblings, 3 replies; 34+ messages in thread From: Robert Dewar @ 2000-05-10 0:00 UTC (permalink / raw) In article <3918BB77.693C70D6@research.canon.com.au>, Geoff Bull <geoff@research.canon.com.au> wrote: > Oops, I posted to comp.lang.ada by mistake! > This was a thread on team-ada discussing which started with > the "2038 bug". > Fair enough, weak was probably the wrong word (maybe I should > used "basic") > - it doesn't even split out hours and minutes. By the way, have a look at the package GNAT.Calendar in GNAT 3.13 which fills in some of the gaps. In fact let me post the spec here. There is also a GNAT.Calendar.Time_IO that allows flexible output of times -- This package extends Ada.Calendar to handle Hour, Minute, Second, -- Second_Duration and Day_Of_Week and Day_In_Year from Calendar.Time. -- Second_Duration precision depends on the target clock precision. -- -- GNAT.Calendar provides the same kind of abstraction found in -- Ada.Calendar. It provides Split and Time_Of to build and split a Time -- data. And it provides accessor functions to get only one of Hour, Minute, -- Second, Second_Duration. Other functions are to access more advanced -- valueas like Day_Of_Week, Day_In_Year and Week_In_Year. with Ada.Calendar; with Interfaces.C; package GNAT.Calendar is type Day_Name is (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday); subtype Hour_Number is Natural range 0 .. 23; subtype Minute_Number is Natural range 0 .. 59; subtype Second_Number is Natural range 0 .. 59; subtype Second_Duration is Ada.Calendar.Day_Duration range 0.0 .. 1.0; subtype Day_In_Year_Number is Positive range 1 .. 366; subtype Week_In_Year_Number is Positive range 1 .. 53; function Hour (Date : Ada.Calendar.Time) return Hour_Number; function Minute (Date : Ada.Calendar.Time) return Minute_Number; function Second (Date : Ada.Calendar.Time) return Second_Number; function Sub_Second (Date : Ada.Calendar.Time) return Second_Duration; -- Hour, Minute, Sedond and Sub_Second returns the complete time data for -- the Date (H:M:S.SS). See Ada.Calendar for Year, Month, Day accessors. -- Second_Duration precision depends on the target clock precision. function Day_Of_Week (Date : Ada.Calendar.Time) return Day_Name; -- Return the day name. function Day_In_Year (Date : Ada.Calendar.Time) return Day_In_Year_Number; -- Returns the day number in the year. (1st January is day 1 and 31st -- December is day 365 or 366 for leap year). function Week_In_Year (Date : Ada.Calendar.Time) return Week_In_Year_Number; -- Returns the week number in the year with Monday as first day of week procedure Split (Date : Ada.Calendar.Time; Year : out Ada.Calendar.Year_Number; Month : out Ada.Calendar.Month_Number; Day : out Ada.Calendar.Day_Number; Hour : out Hour_Number; Minute : out Minute_Number; Second : out Second_Number; Sub_Second : out Second_Duration); -- Split the standard Ada.Calendar.Time data in date data (Year, Month, -- Day) and Time data (Hour, Minute, Second, Sub_Second) function Time_Of (Year : Ada.Calendar.Year_Number; Month : Ada.Calendar.Month_Number; Day : Ada.Calendar.Day_Number; Hour : Hour_Number; Minute : Minute_Number; Second : Second_Number; Sub_Second : Second_Duration := 0.0) return Ada.Calendar.Time; -- Returns an Ada.Calendar.Time data built from the date and time values. -- C timeval conversion -- C timeval represent a duration (used in Select for example). This -- structure is composed of a number of seconds and a number of micro -- seconds. The timeval structure is not exposed here because its -- definition is target dependent. Interface to C programs is done via a -- pointer to timeval structure. type timeval is private; function To_Duration (T : access timeval) return Duration; function To_Timeval (D : Duration) return timeval; private -- This is a dummy declaration that should be the largest possible timeval -- structure of all supported targets. type timeval is array (1 .. 2) of Interfaces.C.long; function Julian_Day (Year : Ada.Calendar.Year_Number; Month : Ada.Calendar.Month_Number; Day : Ada.Calendar.Day_Number) return Integer; -- Compute Julian day number. -- -- The code of this function is a modified version of algorithm -- 199 from the Collected Algorithms of the ACM. -- The author of algorithm 199 is Robert G. Tantzen. end GNAT.Calendar; -- This package augments standard Ada.Text_IO with facilities for input -- and output of time values in standardized format. package GNAT.Calendar.Time_IO is Picture_Error : exception; type Picture_String is new String; -- This is a string to describe date and time output format. The string is -- a set of standard character and special tag that are replaced by the -- corresponding values. It follows the GNU Date specification. Here are -- the recognized directives : -- -- % a literal % -- n a newline -- t a horizontal tab -- -- Time fields: -- -- %H hour (00..23) -- %I hour (01..12) -- %k hour ( 0..23) -- %l hour ( 1..12) -- %M minute (00..59) -- %p locale's AM or PM -- %r time, 12-hour (hh:mm:ss [AP]M) -- %s seconds since 1970-01-01 00:00:00 UTC -- (a nonstandard extension) -- %S second (00..59) -- %T time, 24-hour (hh:mm:ss) -- -- Date fields: -- -- %a locale's abbreviated weekday name (Sun..Sat) -- %A locale's full weekday name, variable length -- (Sunday..Saturday) -- %b locale's abbreviated month name (Jan..Dec) -- %B locale's full month name, variable length -- (January..December) -- %c locale's date and time (Sat Nov 04 12:02:33 EST 1989) -- %d day of month (01..31) -- %D date (mm/dd/yy) -- %h same as %b -- %j day of year (001..366) -- %m month (01..12) -- %U week number of year with Sunday as first day of week -- (00..53) -- %w day of week (0..6) with 0 corresponding to Sunday -- %W week number of year with Monday as first day of week -- (00..53) -- %x locale's date representation (mm/dd/yy) -- %y last two digits of year (00..99) -- %Y year (1970...) -- -- By default, date pads numeric fields with zeroes. GNU date -- recognizes the following nonstandard numeric modifiers: -- -- - (hyphen) do not pad the field -- _ (underscore) pad the field with spaces ISO_Date : constant Picture_String; US_Date : constant Picture_String; European_Date : constant Picture_String; function Image (Date : Ada.Calendar.Time; Picture : Picture_String) return String; -- Return Date as a string with format Picture. -- raise Picture_Error if picture string is wrong procedure Put_Time (Date : Ada.Calendar.Time; Picture : Picture_String); -- Put Date with format Picture. -- raise Picture_Error if picture string is wrong private ISO_Date : constant Picture_String := "%Y/%m/%d"; US_Date : constant Picture_String := "%m/%d/%y"; European_Date : constant Picture_String := "%d/%m/%y"; end GNAT.Calendar.Time_IO; Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: C date package 2000-05-10 0:00 ` Robert Dewar @ 2000-05-10 0:00 ` Ken Garlington 2000-05-10 0:00 ` Geoff Bull 2000-05-10 0:00 ` Geoff Bull 2000-05-10 0:00 ` Ada Calendar oddity <was Re: C date package> Preben Randhol 2 siblings, 1 reply; 34+ messages in thread From: Ken Garlington @ 2000-05-10 0:00 UTC (permalink / raw) Just out of curiosity, I was going to ask why your week started on Monday: > type Day_Name is > (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, > Sunday); > function Week_In_Year (Date : Ada.Calendar.Time) return > Week_In_Year_Number; > -- Returns the week number in the year with Monday as first > day of week and then I noticed the comments in GNAT.Calendar.Time_IO: > It follows the GNU Date > specification. Here are the recognized directives : > -- Date fields: > -- > -- %a locale's abbreviated weekday name (Sun..Sat) > -- %A locale's full weekday name, > variable length > -- (Sunday..Saturday) > -- %U week number of year with Sunday as first > day of week > -- (00..53) > -- %w day of week (0..6) with 0 corresponding to > Sunday > -- %W week number of year with Monday as first > day of week which implies that, although it's acceptable in GNU to start counting weeks on either Sunday or Monday, the first (zero'th) day of the week is always Sunday? Is this right? ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: C date package 2000-05-10 0:00 ` Ken Garlington @ 2000-05-10 0:00 ` Geoff Bull 0 siblings, 0 replies; 34+ messages in thread From: Geoff Bull @ 2000-05-10 0:00 UTC (permalink / raw) Ken Garlington wrote: > > Just out of curiosity, I was going to ask why your week started on Monday: > > > type Day_Name is > > (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, > > Sunday); > > > function Week_In_Year (Date : Ada.Calendar.Time) return > > Week_In_Year_Number; > > -- Returns the week number in the year with Monday as first > > day of week > > which implies that, although it's acceptable in GNU to start counting weeks > on either Sunday or Monday, the first (zero'th) day of the week is always > Sunday? Is this right? ISO8601 defines Monday as the first day of the week when it comes to numbering weeks within years. The first week of the year is the week that contains the first Thursday. ISO8601 also says that Monday is numbered as 1 and Sunday is numbered as 7. Right depends on what "standard" you are applying. Cheers Geoff ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: C date package 2000-05-10 0:00 ` Robert Dewar 2000-05-10 0:00 ` Ken Garlington @ 2000-05-10 0:00 ` Geoff Bull 2000-05-10 0:00 ` Ada Calendar oddity <was Re: C date package> Preben Randhol 2 siblings, 0 replies; 34+ messages in thread From: Geoff Bull @ 2000-05-10 0:00 UTC (permalink / raw) Robert Dewar wrote: > > By the way, have a look at the package GNAT.Calendar in GNAT > 3.13 which fills in some of the gaps. In fact let me post the > spec here. There is also a GNAT.Calendar.Time_IO that allows > flexible output of times Cool! Fortuneately I am using 3.12p so I don't have to admit to failing to look in the library. :-) ^ permalink raw reply [flat|nested] 34+ messages in thread
* Ada Calendar oddity <was Re: C date package> 2000-05-10 0:00 ` Robert Dewar 2000-05-10 0:00 ` Ken Garlington 2000-05-10 0:00 ` Geoff Bull @ 2000-05-10 0:00 ` Preben Randhol 2000-05-10 0:00 ` Tarjei Tj�stheim Jensen 2000-05-10 0:00 ` Robert A Duff 2 siblings, 2 replies; 34+ messages in thread From: Preben Randhol @ 2000-05-10 0:00 UTC (permalink / raw) I was looking yesterday in the RM and found that Year in the Ada.Calendar was defined until 2099 only. I have search on deja, but I cannot find any reason for it to be defined only to 2099. Some would claim that 2099 is a long way in the future, but I think it isn't in all respects. An example: If I were to make a program for issuing drivers licenses here in Norway there would be a problem. Well not immediately but in only 18 years. The reason is that driver's licenses expires as you get 100 years old. So mine expires in 2073. If one wanted to use the Year type in Ada.Calendar for birthday and expiration date, one would get an constraint error when one issued drivers licences for these born this year. Wouldn't one? I may have missed some thing important when I speedily "read" the Ada.Calendar, but this seems a bit odd to me (the upper limit that is). -- Preben Randhol -- [randhol@pvv.org] -- <http://www.pvv.org/~randhol/> "Det eneste trygge stedet i verden er inne i en fortelling." -- Athol Fugard ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-10 0:00 ` Ada Calendar oddity <was Re: C date package> Preben Randhol @ 2000-05-10 0:00 ` Tarjei Tj�stheim Jensen 2000-05-11 0:00 ` Geoff Bull 2000-05-11 0:00 ` Charles Hixson 2000-05-10 0:00 ` Robert A Duff 1 sibling, 2 replies; 34+ messages in thread From: Tarjei Tj�stheim Jensen @ 2000-05-10 0:00 UTC (permalink / raw) Preben Randhol wrote: > An example: If I were to make a program for issuing drivers licenses > here in Norway there would be a problem. Well not immediately but in > only 18 years. > > The reason is that driver's licenses expires as you get 100 years old. So > mine expires in 2073. > > If one wanted to use the Year type in Ada.Calendar for birthday and > expiration date, one would get an constraint error when one issued > drivers licences for these born this year. Wouldn't one? > > I may have missed some thing important when I speedily "read" the > Ada.Calendar, but this seems a bit odd to me (the upper limit that is). That would be a wrong use of the type. The drivers license "problem" is a database issue. You should not use something that is internal to Ada in that context. Greetings, ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-10 0:00 ` Tarjei Tj�stheim Jensen @ 2000-05-11 0:00 ` Geoff Bull 2000-05-11 0:00 ` Gautier 2000-05-11 0:00 ` Charles Hixson 1 sibling, 1 reply; 34+ messages in thread From: Geoff Bull @ 2000-05-11 0:00 UTC (permalink / raw) "Tarjei Tj�stheim Jensen" wrote: > > > If one wanted to use the Year type in Ada.Calendar for birthday and > > expiration date, one would get an constraint error when one issued > > drivers licences for these born this year. Wouldn't one? > That would be a wrong use of the type. The drivers license "problem" is > a database issue. You should not use something that is internal to Ada > in that context. So when you read a date from the database, what type should you use? If you avoid using Ada.Calendar how do you compare the database time with the today's date, e.g.? ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-11 0:00 ` Geoff Bull @ 2000-05-11 0:00 ` Gautier 2000-05-12 0:00 ` Geoff Bull 0 siblings, 1 reply; 34+ messages in thread From: Gautier @ 2000-05-11 0:00 UTC (permalink / raw) Geoff Bull: > So when you read a date from the database, what type should you use? > If you avoid using Ada.Calendar how do you compare the database time > with the today's date, e.g.? Simple ;-) : you make a package Long_Calendar with all operators and also conversions from and to Ada.Calendar. It could use the Julian date. NB: the problem occurs also with data prior to 1901 - it exists, e.g. for environmental statistics with precise dates ! Check Deja News for a hot debate that happened some year(s) ago on this topic... _____________________________________________ Gautier -- http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-11 0:00 ` Gautier @ 2000-05-12 0:00 ` Geoff Bull 2000-05-12 0:00 ` Gautier 0 siblings, 1 reply; 34+ messages in thread From: Geoff Bull @ 2000-05-12 0:00 UTC (permalink / raw) Gautier wrote: > > Geoff Bull: > > > So when you read a date from the database, what type should you use? > > If you avoid using Ada.Calendar how do you compare the database time > > with the today's date, e.g.? > > Simple ;-) : you make a package Long_Calendar with all operators > and also conversions from and to Ada.Calendar. Sure, but you only have to do this because of the inadequacy of Ada.Calendat, not because it is funadanmentally bad practice to use the standard Ada libraries (that is how I interpreted what "Tarjei Tj�stheim Jensen" wrote - in restrospect, I realise he meant that is was incorrect to use Ada.Calendar in this context because Ada.Calendar was incapable of doing the job at hand). ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-12 0:00 ` Geoff Bull @ 2000-05-12 0:00 ` Gautier 2000-05-11 0:00 ` Al Christians 0 siblings, 1 reply; 34+ messages in thread From: Gautier @ 2000-05-12 0:00 UTC (permalink / raw) Geoff Bull: > > Simple ;-) : you make a package Long_Calendar with all operators > > and also conversions from and to Ada.Calendar. > Sure, but you only have to do this because of the inadequacy > of Ada.Calendar, not because it is fundamentally bad practice > to use the standard Ada libraries. I'm also from the opinion that the range for years in Ada.Calendar is really too narrow - hence the smiley... Maybe widen this range for Ada 0X ?... _____________________________________________ Gautier -- http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-12 0:00 ` Gautier @ 2000-05-11 0:00 ` Al Christians 0 siblings, 0 replies; 34+ messages in thread From: Al Christians @ 2000-05-11 0:00 UTC (permalink / raw) I note that your posting shows up on my browser with the date using 25 bytes in the header. If the internet can use such inefficient formats, there is not much excuse for serious programmers sacrificing range and scale by shaving bits. For example, using only 16 bytes, eg 128 bits, eg representing seconds with 64 bits to the left of the binary point and 64 to the right, I think we get a range about a thousand times the age of the universe and a precision shorter than the time it takes anything to happen, except that if I've made a mistake here, someone will take less than 2^(-64) seconds to point it out. Not many applications would need more range or scale than that, would they? Al Gautier wrote: > > > I'm also from the opinion that the range for years in Ada.Calendar > is really too narrow - hence the smiley... Maybe widen this range > for Ada 0X ?... > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-10 0:00 ` Tarjei Tj�stheim Jensen 2000-05-11 0:00 ` Geoff Bull @ 2000-05-11 0:00 ` Charles Hixson 2000-05-11 0:00 ` Tarjei Tj�stheim Jensen 1 sibling, 1 reply; 34+ messages in thread From: Charles Hixson @ 2000-05-11 0:00 UTC (permalink / raw) "Tarjei Tj�stheim Jensen" wrote: > Preben Randhol wrote: > --snip > > The reason is that driver's licenses expires as you get 100 years old. So > > mine expires in 2073. > > > > If one wanted to use the Year type in Ada.Calendar for birthday and > > expiration date, one would get an constraint error when one issued > > drivers licences for these born this year. Wouldn't one? > --snip. > > That would be a wrong use of the type. The drivers license "problem" is > a database issue. You should not use something that is internal to Ada > in that context. > > Greetings, This seems to imply the assumption that the database would not be implemented in Ada. For some purposes this is reasonable (SQL is frequently nice, and has already been done). For other purposes it doesn't seem reasonable at all. If I don't need a full relational database, why should I need to drag one along? ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-11 0:00 ` Charles Hixson @ 2000-05-11 0:00 ` Tarjei Tj�stheim Jensen 2000-05-12 0:00 ` Charles Hixson 0 siblings, 1 reply; 34+ messages in thread From: Tarjei Tj�stheim Jensen @ 2000-05-11 0:00 UTC (permalink / raw) Charles Hixson wrote: > > This seems to imply the assumption that the database would not be implemented > in Ada. For some purposes this is reasonable (SQL is frequently nice, and has > already been done). For other purposes it doesn't seem reasonable at all. If > I don't need a full relational database, why should I need to drag one along? 1. Because a full relational database is VERY nice to have and causes few surprises. It is not a matter of not needing one. It is a matter of not being able to use one. 2. The Ada type is simply not apropriate in this context. This is a typical DP application. When doing DP stuff, do it the way DP stuff should be done. 3. When implementing Ada support for the database one makes sure that one includes the proper date/time stuff into the support library. Greetings, ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-11 0:00 ` Tarjei Tj�stheim Jensen @ 2000-05-12 0:00 ` Charles Hixson 2000-05-12 0:00 ` Tarjei Tj�stheim Jensen 0 siblings, 1 reply; 34+ messages in thread From: Charles Hixson @ 2000-05-12 0:00 UTC (permalink / raw) "Tarjei Tj�stheim Jensen" wrote: > Charles Hixson wrote: > > > > This seems to imply the assumption that the database would not be implemented > > in Ada. For some purposes this is reasonable (SQL is frequently nice, and has > > already been done). For other purposes it doesn't seem reasonable at all. If > > I don't need a full relational database, why should I need to drag one along? > > 1. Because a full relational database is VERY nice to have and causes > few surprises. It is not a matter of not needing one. It is a matter of > not being able to use one.\ It's certainly nice for a programmer to have the choice of using a relational database, but for many applications it is extreme overkill, and causes the applications to bloat so much that more expensive hardware is required to run them. Sometimes one even wants to store the data in a flat file, load it all into RAM at program start, and then (maybe) write out any changes at the end. Relational is only one option. > 2. The Ada type is simply not apropriate in this context. This is a > typical DP application. When doing DP stuff, do it the way DP stuff > should be done. If you are talking about the predefined types, then sometimes yes, sometimes no. But one can always choose to define a type appropriate to the problem at hand. "Should" is, by definition, correct. But I doubt that we are in agreement as to what "the way DP stuff should be done" means. I see this as very context dependent. > 3. When implementing Ada support for the database one makes sure that > one includes the proper date/time stuff into the support library. If one is using a preexisting private library, then this is correct. But different applications have very different needs. Sometimes the most important thing is that they be cheap, portable, and small. Basic ISAM will let one handle many things with a lot less weight than a full RDBMS. And a stand-alone executable file is sometimes what one really wants. > Greetings, ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-12 0:00 ` Charles Hixson @ 2000-05-12 0:00 ` Tarjei Tj�stheim Jensen 0 siblings, 0 replies; 34+ messages in thread From: Tarjei Tj�stheim Jensen @ 2000-05-12 0:00 UTC (permalink / raw) Charles Hixson wrote: > It's certainly nice for a programmer to have the choice of using a relational > database, but for many applications it is extreme overkill, and causes the > applications to bloat so much that more expensive hardware is required to run them. > Sometimes one even wants to store the data in a flat file, load it all into RAM at > program start, and then (maybe) write out any changes at the end. Relational is > only one option. It is usually the other way around. One finds that the use of a database make it possible to get more from your data. And the various report tools gives you a lot of interesting possibilities which you don't normally get if you do everything by yourself. That is why databases are popular. If the database requires a hot iron to run it, it just means that you either have done a bad programming job or you underestimated the size of the project. In fact a lot of people are spending time moving a lot of flat files to databases in order to get database benefits. > If you are talking about the predefined types, then sometimes yes, sometimes no. > But one can always choose to define a type appropriate to the problem at hand. > "Should" is, by definition, correct. But I doubt that we are in agreement as to > what "the way DP stuff should be done" means. I see this as very context dependent. Possibly. I'm quite convinced that a DP person would have no problem understanding what I meant. > > 3. When implementing Ada support for the database one makes sure that > > one includes the proper date/time stuff into the support library. > > If one is using a preexisting private library, then this is correct. But different > applications have very different needs. Sometimes the most important thing is that > they be cheap, portable, and small. Basic ISAM will let one handle many things with > a lot less weight than a full RDBMS. And a stand-alone executable file is sometimes > what one really wants. Basic ISAM will go wrong in a lot more ways and more times than your ordinary commercial grade database. In this context mysql and its like are not a commercial grade database. Postgresql is. Greetings, ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-10 0:00 ` Ada Calendar oddity <was Re: C date package> Preben Randhol 2000-05-10 0:00 ` Tarjei Tj�stheim Jensen @ 2000-05-10 0:00 ` Robert A Duff 2000-05-10 0:00 ` Preben Randhol 2000-05-17 0:00 ` Robert I. Eachus 1 sibling, 2 replies; 34+ messages in thread From: Robert A Duff @ 2000-05-10 0:00 UTC (permalink / raw) randhol+nospam@pvv.org (Preben Randhol) writes: > I was looking yesterday in the RM and found that Year in the > Ada.Calendar was defined until 2099 only. I have search on deja, but I > cannot find any reason for it to be defined only to 2099. The reason for the range 1901..2099 is that leap year calculations are simpler (and more efficient) in this range -- in this range, all years divisible by 4 are leap years (including 2000). 1900 and 2100 are not leap years. One can argue about whether that's a *good* reason, but it's the reason. What range would *you* suggest? If I were designing such a package, I would think about the number of bits needed to represent the number of seconds (or nanoseconds?) in the range. - Bob ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-10 0:00 ` Robert A Duff @ 2000-05-10 0:00 ` Preben Randhol 2000-05-10 0:00 ` Charles Hixson 2000-05-17 0:00 ` Robert I. Eachus 1 sibling, 1 reply; 34+ messages in thread From: Preben Randhol @ 2000-05-10 0:00 UTC (permalink / raw) On Wed, 10 May 2000 13:44:39 GMT, Robert A Duff wrote: >randhol+nospam@pvv.org (Preben Randhol) writes: > >The reason for the range 1901..2099 is that leap year calculations are >simpler (and more efficient) in this range -- in this range, all years >divisible by 4 are leap years (including 2000). 1900 and 2100 are not >leap years. Ah I see. >What range would *you* suggest? Well that would perhaps depend on the implementation I guess. If one defined the upper limit to 9999 one would get a very big number trying to calculate the numbers of seconds from today until say year 7000. >If I were designing such a package, I would think about the number of >bits needed to represent the number of seconds (or nanoseconds?) in the >range. I think that in this case one needs to use another type for the birth and expiration date and convert from Ada.Calendar the date of today if one also wants the date when the license was issued. -- Preben Randhol -- [randhol@pvv.org] -- <http://www.pvv.org/~randhol/> "Det eneste trygge stedet i verden er inne i en fortelling." -- Athol Fugard ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-10 0:00 ` Preben Randhol @ 2000-05-10 0:00 ` Charles Hixson 2000-05-11 0:00 ` Geoff Bull 0 siblings, 1 reply; 34+ messages in thread From: Charles Hixson @ 2000-05-10 0:00 UTC (permalink / raw) Preben Randhol wrote: > -- snip > >If I were designing such a package, I would think about the number of > >bits needed to represent the number of seconds (or nanoseconds?) in the > >range. > > I think that in this case one needs to use another type for the birth > and expiration date and convert from Ada.Calendar the date of today if one > also wants the date when the license was issued. > > -- > Preben Randhol -- [randhol@pvv.org] -- <http://www.pvv.org/~randhol/> > "Det eneste trygge stedet i verden er inne i en fortelling." > -- Athol Fugard It seems to me that it is a mistake to include seconds, much less any smaller unit, in the calendar date. I'm not sure that minutes is justified, but if one uses a 64 bit number then it wouldn't seem to cause any problems. (Calendar corrections for seconds are SO much more common than corrections for minutes!) 2^63 minutes would seem to express any particular time that one would want to talk about. Perhaps Calendar and Time could be two separate packages, each using a 64-bit number as their base, one based on days and the other based on ?nano?-seconds. Or time could be defined with the top 32 bits being equivalent to the bottom 32 bits of Calendar, and the "lower" 32 bits being a floating point number guaranteed to be less than 1, a fractional number of minutes. This would allow DateTime to be a 96 bit number good for (nearly) everything. This would make formatting the I/O a bit of work, but would make date and time calculations very simple. It seems to me that one would gain on one would more than make up for what one would loose on the other (I calculate with Time-s a lot more than I display them). ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-10 0:00 ` Charles Hixson @ 2000-05-11 0:00 ` Geoff Bull 2000-05-11 0:00 ` Charles Hixson 0 siblings, 1 reply; 34+ messages in thread From: Geoff Bull @ 2000-05-11 0:00 UTC (permalink / raw) Charles Hixson wrote: > > It seems to me that it is a mistake to include seconds, much less any smaller > unit, in the calendar date. Astronomers and real time programers, e.g., might not agree with you. Although, of course, the latter group are catered for with Ada.Real_Time. > I'm not sure that minutes is justified, but if Depends on what requirement you are trying to meet. > one uses a 64 bit number then it wouldn't seem to cause any problems. Elsewhere it has already been stated that no more than 32 bits is essential (I have no opinion on this0. > Perhaps Calendar and Time could be two separate packages, each using a 64-bit > number as their base, one based on days and the other based on > ?nano?-seconds. This is perhaps not a bad idea, because seconds and days are different concepts, one being a fixed period of time, the other being the variable amount of time for one rotation of the earth (either wrt to the sun or the stars). > Or time could be defined with the top 32 bits being ... Of course it would be defined as a private type. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-11 0:00 ` Geoff Bull @ 2000-05-11 0:00 ` Charles Hixson 2000-05-12 0:00 ` Geoff Bull 0 siblings, 1 reply; 34+ messages in thread From: Charles Hixson @ 2000-05-11 0:00 UTC (permalink / raw) Thanks for the reply. Some responses follow (interspersed as appropriate). Geoff Bull wrote: > Charles Hixson wrote: > > > > It seems to me that it is a mistake to include seconds, much less any smaller > > unit, in the calendar date. > > Astronomers and real time programers, e.g., might not agree > with you. Although, of course, the latter group are catered > for with Ada.Real_Time. > > > I'm not sure that minutes is justified, but if > > Depends on what requirement you are trying to meet. I was assuming a split between the Calendar class and the Time class. Clearly if one is building a DateTime class then minutes *MUST* be included. > > one uses a 64 bit number then it wouldn't seem to cause any problems. > > Elsewhere it has already been stated that no more than 32 bits > is essential (I have no opinion on this0. But the 64 bit chips are starting to become more common. How many bits is essential depends on what one is trying to do (and the degree of precision). By some measures all that one needs is the floating point (32 bit!) # of years since, say the founding of the city of Rome (i.e., A.U.C. dating). But many wouldn't find that convenient. (And date/time formatting from that to the current calendar would be a real nuisance!) > > Perhaps Calendar and Time could be two separate packages, each using a 64-bit > > number as their base, one based on days and the other based on > > ?nano?-seconds. > > This is perhaps not a bad idea, because seconds and days are > different concepts, one being a fixed period of time, the other > being the variable amount of time for one rotation of the earth > (either wrt to the sun or the stars). I was thinking of days as being solar, and of seconds as being determined by atomic clocks, but this probably doesn't signify. > > Or time could be defined with the top 32 bits being ... > > Of course it would be defined as a private type. Well, yes. But the implementor would need to be able to share information between the Date and Time packages. Of course, I may be making things more complex than necessary. I don't know how many bits of precision a 64 bit float would have, but suppose one measured the number of days since 01/01/1904 (in honor of the Macintosh [I think that's the right date!]). To what precision could 12:01:03.14159 of 3000/01/31 be represented? Of course, if this course is chosen, then one will need to figure out what to do when a "leap second" is announced. I was trying to skip out of that problem. Otherwise a sufficiently precise floating point number would do all that one needed (except for nicely formatted I/O). The remaining problem would be how to specify the degree of accuracy to which the time was known. Consider "early in the morning of July 30 this year" or "sometime in the late summer, of 4 BC" or "around 200,000 years ago". These are all times, specified to varying degrees of accuracy. A slightly different kind of problem is "early in the spring, about a decade ago" where the time of year is specified vaguely, but which year, itself, is not specified. This probably won't be handleable by any reasonable time class, but needs consideration (as a representative of a class of problems). ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-11 0:00 ` Charles Hixson @ 2000-05-12 0:00 ` Geoff Bull 0 siblings, 0 replies; 34+ messages in thread From: Geoff Bull @ 2000-05-12 0:00 UTC (permalink / raw) Charles Hixson wrote: > But the 64 bit chips are starting to become more common. You would probably want to have Extended_Calendar in an optional annex, e.g. information systems. The RM only requires 16 bit ints, 24 bit fixed and single precision floats (32 bit). I can't see people being too enthused about forcing these limits up to 64 bit just to make date/time more useful. > I was thinking of days as being solar, and of seconds as being determined by atomic > clocks, but this probably doesn't signify. Atomic clocks are convenient because you can get TAI and UTC (they differ only by leap seconds) from GPS (including leap second broadcasts). It is reasonable to assume that *most* implementations can relate local time to UTC by a time zone offset. > I don't know how many bits of precision a 64 bit float would have, 3.5.7 (15) If Long_Float is predefined for an implementation, then its requested decimal precision shall be at least 11. > suppose one measured the number of days since 01/01/1904 (in honor of the Macintosh > [I think that's the right date!]). Why can't we just use the epoch for TAI? > A slightly different kind of problem is "early in the spring, about a decade ago" > where the time of year is specified vaguely, but which year, itself, is not > specified. I saw a name for this time system somewhere. The example was if you referred to the "'50s" you mean the period 1946 to 1954. The name of this system escapes me, but it is a sufficiently fuzzy concept to be of no use for defining a Calendar package. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-10 0:00 ` Robert A Duff 2000-05-10 0:00 ` Preben Randhol @ 2000-05-17 0:00 ` Robert I. Eachus 2000-05-19 0:00 ` Geoff Bull 1 sibling, 1 reply; 34+ messages in thread From: Robert I. Eachus @ 2000-05-17 0:00 UTC (permalink / raw) Robert A Duff wrote: > The reason for the range 1901..2099 is that leap year calculations are > simpler (and more efficient) in this range -- in this range, all years > divisible by 4 are leap years (including 2000). 1900 and 2100 are not > leap years. True, but that was the reason it was that way in Ada 83, when avoiding the Y2K bug was a big deal. Incidently, note that even in that range there are countries that switched from the Julian to the Gregorian calendar, so dates in early 1900's have to be taken with a grain of salt. There was some discussion of changing the range for the year subtype in Ada 95, but it was felt to be unnecessary. However, several changes in the details were made so that Ada.Calendar.Time does not have an imposed limit. This was felt to be a minor upwardly compatible change, while forcing existing compilers to change the underlying types to support some fixed wider range would have imposed much more work. This allows a Split procedure (probably a in child package of Calendar) to be provided by an implementation which supports a wider range of years. Note also that it would be nice to have child packages for other calendars, such as Chinese, Japanese, Jewish, and Muslim. I have done some work on how to provide such packages, but there are serious problems of definition if you try to extend the date ranges significantly. It doesn't make much sense to take Gregorian dates back before the 16th century, but the Julian calendar needs to carefully deal with the lack of a year zero, and there have been several calendar "reforms" which moved things around. It is nice to be able to use the same date as someone living in that era would have--but it is not a very easy job. In some cases there are suspected mis-correlations of hundreds of years. By Ada0X or Ada1Y or whatever, there should be a much wider agreement on how the Ada.Calendar.Year subtype should be redefined, and maybe on a rich set of subpackages to deal with other calendars. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-17 0:00 ` Robert I. Eachus @ 2000-05-19 0:00 ` Geoff Bull 2000-05-19 0:00 ` Robert I. Eachus 2000-05-21 0:00 ` Robert Dewar 0 siblings, 2 replies; 34+ messages in thread From: Geoff Bull @ 2000-05-19 0:00 UTC (permalink / raw) "Robert I. Eachus" wrote: > > Robert A Duff wrote: > > > The reason for the range 1901..2099 is that leap year calculations are > > simpler (and more efficient) in this range -- in this range, all years > > divisible by 4 are leap years (including 2000). 1900 and 2100 are not > > leap years. > > True, but that was the reason it was that way in Ada 83, when > avoiding the Y2K bug was a big deal. It was that kind of narrow (focussed on one problem) thinking that led to the y2k bug! ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-19 0:00 ` Geoff Bull @ 2000-05-19 0:00 ` Robert I. Eachus 2000-05-21 0:00 ` Robert Dewar 2000-05-21 0:00 ` Robert Dewar 1 sibling, 1 reply; 34+ messages in thread From: Robert I. Eachus @ 2000-05-19 0:00 UTC (permalink / raw) Geoff Bull wrote: > It was that kind of narrow (focussed on one problem) thinking > that led to the y2k bug! That definitely was not the case. The fact that Year had a constraint, and the range of that constraint were both discussed--at length during the standardization process. The "Ada Doom Date" of December 31, 2099 was well known, with the realization that it would need to be fixed in a subsequent version of the standard. I don't know of anyone who has had problems due to the 2099 limit, but there are several cases where the 1901 limit made Calendar.Time an unsuitable choice for representing birthdates. During the Ada 9X revision, this issue was revisited, and the doom date, as such, wasl removed. An implementation can provide a Calendar.Time type with a range significantly larger than two hundred years and not have to make an explicit check for the doom date in the arithmetic operators. This change is found in RM 9.6(26). As I said in the previous post, I expect that the Year_Number subtype will be extended in a future version of the standard. (Changing the range for Year_Number would require a different representation for variables of type Calendar.Time. This is simething that needs to be done slowly, and with plenty of warning to the compiler vendors.) On the other hand, a new Long_Time type would cause fewer upward compatibility problems. ;-) ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-19 0:00 ` Robert I. Eachus @ 2000-05-21 0:00 ` Robert Dewar 0 siblings, 0 replies; 34+ messages in thread From: Robert Dewar @ 2000-05-21 0:00 UTC (permalink / raw) In article <3924D3FF.11D8C99A@earthlink.net>, "Robert I. Eachus" <rieachus@earthlink.net> wrote: (Changing the > range > for Year_Number would require a different representation for variables > of type Calendar.Time. This is simething that needs to be done slowly, > and with plenty of warning to the compiler vendors.) On the other hand, > a new Long_Time type would cause fewer upward compatibility problems. What really *is* the situation with Ada 95 compilers. Certainly in GNAT we chose a representation for Calendar.Time that can accomodate very wide ranges of times and dates (Calendar.Time is kept in units of nanoseconds stored in a signed 64 bit value which represents very wide time ranges -- tens of thousands of years at least). It certainly is the case that representations of Calendar.Time are the worrisome thing here (think for example of such values written on files). A compiler that has chosen a narrow range representation for this type has, in my view, made a significant mistake which will cause nasty compatibility problems later, but I don't know specifically that any compilers have made this choice. Anyone know what other Ada 95 compilers do? Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-19 0:00 ` Geoff Bull 2000-05-19 0:00 ` Robert I. Eachus @ 2000-05-21 0:00 ` Robert Dewar [not found] ` <392869F0.D88F056A@acenet.com.au> 1 sibling, 1 reply; 34+ messages in thread From: Robert Dewar @ 2000-05-21 0:00 UTC (permalink / raw) In article <3924B35E.DC0C9CDF@acenet.com.au>, Geoff Bull <gbull@acenet.com.au> wrote: > It was that kind of narrow (focussed on one problem) thinking > that led to the y2k bug! No, that's a mis-characterization. The Y2K bug was a product of two unrelated phenomena: 1. Legacy code had a life time much longer than expected. 2. COBOL has very poor data abstraction capabilities, so the problem could not be solved in the obvious manner, even for well written code. In the case of Ada, it is arguable whether todays legacy code will last a hundred years in unchanged form. In any case, well written code will simply not be dependent on the range in any case, so changing the range will have no effect on existing code. If anyone was interested for example, it would be trivial to provide a version of Calendar for GNAT that did not have this limit (it requires a couple of declarations to be changed, and one simple test added to the leap year circuit). Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <392869F0.D88F056A@acenet.com.au>]
* Re: Ada Calendar oddity <was Re: C date package> [not found] ` <392869F0.D88F056A@acenet.com.au> @ 2000-05-22 0:00 ` Tarjei Tj�stheim Jensen 2000-05-27 0:00 ` Reinert Korsnes 2000-06-03 0:00 ` Robert I. Eachus 1 sibling, 1 reply; 34+ messages in thread From: Tarjei Tj�stheim Jensen @ 2000-05-22 0:00 UTC (permalink / raw) Geoff Bull wrote: > Maybe, but I can't use Ada.Calendar to represent dates more than > ~ +/- 100 years from today's date. > It is beyond me why I need to create my own date package if I want to > do more than look at today's date To me it look like you are trying to use the calendar package for something that it was not intended to do. Perhaps the name calendar is wrong? If you want to handle dates and times outside internal Ada scheduling, I think you are supposed to create your own stuff. Greetings, ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-22 0:00 ` Tarjei Tj�stheim Jensen @ 2000-05-27 0:00 ` Reinert Korsnes 2000-05-27 0:00 ` Tarjei Tj�stheim Jensen 0 siblings, 1 reply; 34+ messages in thread From: Reinert Korsnes @ 2000-05-27 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1027 bytes --] In article <39298C83.7794DDB8@online.no>, "Tarjei Tj�stheim Jensen" <tarjei@online.no> writes: |> Geoff Bull wrote: |> > Maybe, but I can't use Ada.Calendar to represent dates more than |> > ~ +/- 100 years from today's date. |> > It is beyond me why I need to create my own date package if I want to |> > do more than look at today's date |> |> To me it look like you are trying to use the calendar package for |> something that it was not intended to do. Perhaps the name calendar is |> wrong? |> |> If you want to handle dates and times outside internal Ada scheduling, I |> think you are supposed to create your own stuff. But I love Ada.Calendar. So elegant. I use it under gnat and calsulate times/durations over 10-20 years.... (when treating environment data). But the conclusion is that I then do something really dirty ? reinert |> |> |> Greetings, -- Norwegian Polar Institute Polar Environment Center N-9296 Tromso Norway Fax: +47 77750501 http://geophys.npolar.no/~reinert/personal.html ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> 2000-05-27 0:00 ` Reinert Korsnes @ 2000-05-27 0:00 ` Tarjei Tj�stheim Jensen 0 siblings, 0 replies; 34+ messages in thread From: Tarjei Tj�stheim Jensen @ 2000-05-27 0:00 UTC (permalink / raw) Reinert Korsnes wrote: > But I love Ada.Calendar. So elegant. I use it under gnat and > calsulate times/durations over 10-20 years.... (when treating environment > data). But the conclusion is that I then do something really dirty ? Not if you are using it for internal calculations, are aware of its limitations and do not store any of it externally for others to use. The moment you store it in an external file it is time to make sure you are storing something that is portable. Greetings, ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada Calendar oddity <was Re: C date package> [not found] ` <392869F0.D88F056A@acenet.com.au> 2000-05-22 0:00 ` Tarjei Tj�stheim Jensen @ 2000-06-03 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 34+ messages in thread From: Robert I. Eachus @ 2000-06-03 0:00 UTC (permalink / raw) Geoff Bull wrote: > Maybe, but I can't use Ada.Calendar to represent dates more than > ~ +/- 100 years from today's date. > It is beyond me why I need to create my own date package if I want to > do more than look at today's date First of all, using Time_Of, Split, and Year for dates in the early 20th century gets increasingly iffy, since conversions from the Julian to the Gregorian calendar occurred at different times around the world. The hard problem is to provide meaningful conversions of values of Calendar.Time to Gregorian dates and vice-versa. Not only is there a programming programming, but of converting "old" dates correctly is not easy. I can fairly easily whip up a child package containing versions of Split and Time_Of with an extra parameter (Julian or Gregorian), and leave it up to the user to figure out when to use what, but that alone is not enough. Which is the first day of the year? Julius Caesar agreed reluctantly to January 1 instead of the Ides of March, but even in colonial America, some people used March 20th or other spring solstice dates. A more interesting version date package would have a location parameter, and embed the different date rules for various locales. (Sweden is particularly messy.) Just specialing to the country is not enough, the area that is now the United States had five different calendar conversions, actually six since you have to count the French Revolutionary calendar. Also as you go back in time beyond the establishment of the Julian calendar, there are anomalies in the Julian calendar. Everyone knows that there was no year zero, but Ceaser Agustus also messed up the length of the months at about that time. And Julius began the new calendar with two odd length months. Projecting into the future is even more difficult. When will there next be a change in the calendar? The length of the day is changing due to the tidal influence of the moon, and in any case the Gregorian calendar is drifting anyway. Will 3000 be a leap year? Or is 4000 a better choice? It might be reasonable to decide that soon, but will the Gregorian calendar even be in use a thousand years from now? A few years back, the so called World Calendar, with two intercalciary days was proposed so that holidays would occur on the same day of the week every year. (In the US, we seem to have used a different method of accomplishing that.) The Chinese and Islamic calendars are still in widespread use, and who knows what new calendars will be proposed. (The Hebrew calendar is still used as well, but mostly for religous purposes. Every bill passed by the US Congress has a date since July 4th 1776, but only a few people pay attention now. Early on for the United States, it was important to do that, since not everyone was using the same calendar.) ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2000-06-03 0:00 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <l0313030eb53d1408aee7@[144.205.16.58]> 2000-05-09 0:00 ` C date package Geoff Bull 2000-05-09 0:00 ` Geoff Bull 2000-05-09 0:00 ` Robert Dewar 2000-05-10 0:00 ` Geoff Bull 2000-05-10 0:00 ` Robert Dewar 2000-05-10 0:00 ` Ken Garlington 2000-05-10 0:00 ` Geoff Bull 2000-05-10 0:00 ` Geoff Bull 2000-05-10 0:00 ` Ada Calendar oddity <was Re: C date package> Preben Randhol 2000-05-10 0:00 ` Tarjei Tj�stheim Jensen 2000-05-11 0:00 ` Geoff Bull 2000-05-11 0:00 ` Gautier 2000-05-12 0:00 ` Geoff Bull 2000-05-12 0:00 ` Gautier 2000-05-11 0:00 ` Al Christians 2000-05-11 0:00 ` Charles Hixson 2000-05-11 0:00 ` Tarjei Tj�stheim Jensen 2000-05-12 0:00 ` Charles Hixson 2000-05-12 0:00 ` Tarjei Tj�stheim Jensen 2000-05-10 0:00 ` Robert A Duff 2000-05-10 0:00 ` Preben Randhol 2000-05-10 0:00 ` Charles Hixson 2000-05-11 0:00 ` Geoff Bull 2000-05-11 0:00 ` Charles Hixson 2000-05-12 0:00 ` Geoff Bull 2000-05-17 0:00 ` Robert I. Eachus 2000-05-19 0:00 ` Geoff Bull 2000-05-19 0:00 ` Robert I. Eachus 2000-05-21 0:00 ` Robert Dewar 2000-05-21 0:00 ` Robert Dewar [not found] ` <392869F0.D88F056A@acenet.com.au> 2000-05-22 0:00 ` Tarjei Tj�stheim Jensen 2000-05-27 0:00 ` Reinert Korsnes 2000-05-27 0:00 ` Tarjei Tj�stheim Jensen 2000-06-03 0:00 ` Robert I. Eachus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox