* Calendar - leap seconds @ 2001-03-17 17:46 singlespeeder 2001-03-18 15:53 ` Wilhelm Spickermann 0 siblings, 1 reply; 11+ messages in thread From: singlespeeder @ 2001-03-17 17:46 UTC (permalink / raw) How do I handle leap seconds using Ada.Calendar as the subtype Day_Duration doesn't have enough space for them? ARM 9.6(11): subtype Day_Duration is Duration range 0.0 .. 86_400.0; Am I best just declaring my own subtype with the required range? singlespeeder ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: Calendar - leap seconds 2001-03-17 17:46 Calendar - leap seconds singlespeeder @ 2001-03-18 15:53 ` Wilhelm Spickermann 2001-03-19 3:47 ` Nick Roberts 2001-03-20 11:34 ` Joseph P Vlietstra 0 siblings, 2 replies; 11+ messages in thread From: Wilhelm Spickermann @ 2001-03-18 15:53 UTC (permalink / raw) To: comp.lang.ada [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1086 bytes --] On 17-Mar-01 singlespeeder wrote: > How do I handle leap seconds using Ada.Calendar as the subtype > Day_Duration > doesn't have enough space for them? > > ARM 9.6(11): > subtype Day_Duration is Duration range 0.0 .. 86_400.0; > > > Am I best just declaring my own subtype with the required range? But, will it help? Does Your operating system still support leap seconds? AFAIK the BIG problem is, that most operating systems no longer support leap seconds, as POSIX has switched to ignoring them (<a time_t value of 536457599 shall correspond to "Wed Dec 31 23:59:59 UTC 1986">). I don�t have the IEEE 1003.1 standard, but I�ve heard, that they even gave an arithmetic expression for computing a time_t value from a broken time (without using a leap second list). Do our library implementations depend on this? My first impression for GNAT is that they do. So I cannot switch my Operating System (Linux) from using /usr/share/zoneinfo/posix/Europe/Berlin (no leap seconds) to /usr/share/zoneinfo/right/Europe/Berlin (with leap seconds) without breaking Ada. :-( Wilhelm ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calendar - leap seconds 2001-03-18 15:53 ` Wilhelm Spickermann @ 2001-03-19 3:47 ` Nick Roberts 2001-03-19 14:43 ` Robert A Duff 2001-03-20 11:34 ` Joseph P Vlietstra 1 sibling, 1 reply; 11+ messages in thread From: Nick Roberts @ 2001-03-19 3:47 UTC (permalink / raw) I'm going to upset people here :-/ but Ada.Calendar should never have dealt with the extremely thorny issue of converting continuous absolute time to and from a calendrical system such as Gregorian (or whatever you want to call it). It should have been called Ada.Time_Functions and simply had two functions such as To_MJD(:Time) and To_Time(:MJD).* There could then have been an optional package Ada.Text_IO.Gregorian_Calendar, as well as perhaps Ada.Text_IO.Time_Within_Day (for hours minutes and seconds), etc. Ah well. That's with the benefit of hindsight, I suppose. -- Nick Roberts http://www.AdaOS.org * MJD: the Modified Julian Date system, offset but otherwise identical to the system astronomers use to reckon absolute time on a simple continuous scale. The unit is SI seconds. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calendar - leap seconds 2001-03-19 3:47 ` Nick Roberts @ 2001-03-19 14:43 ` Robert A Duff 2001-03-19 20:10 ` Laurent Guerby 0 siblings, 1 reply; 11+ messages in thread From: Robert A Duff @ 2001-03-19 14:43 UTC (permalink / raw) "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes: > I'm going to upset people here :-/ but Ada.Calendar should never have dealt > with the extremely thorny issue of converting continuous absolute time to > and from a calendrical system such as Gregorian (or whatever you want to > call it). It should have been called Ada.Time_Functions and simply had two > functions such as To_MJD(:Time) and To_Time(:MJD).* > > There could then have been an optional package > Ada.Text_IO.Gregorian_Calendar, as well as perhaps > Ada.Text_IO.Time_Within_Day (for hours minutes and seconds), etc. I'm not sure why moving some of the functionality to a Gregorian_Calendar package would "upset" anyone. It seems like a fairly minor change. I do think it's a mistake to have the Clock function in the same package as all those conversion functions. Clock is doing I/O, and shouldn't be mixed with the rest (the rest being "pure" code). I see the same mistake in Text_IO -- it mixes formatting with I/O. I find it annoying, for example, that if I want decimal-formatted integer, I can use 'Image, but if I want hexdecimal, I have to import Text_IO (or write my own). Hexadecimal formatting has nothing directly to do with I/O of character strings! - Bob ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calendar - leap seconds 2001-03-19 14:43 ` Robert A Duff @ 2001-03-19 20:10 ` Laurent Guerby 2001-03-20 10:26 ` Nick Roberts 0 siblings, 1 reply; 11+ messages in thread From: Laurent Guerby @ 2001-03-19 20:10 UTC (permalink / raw) Robert A Duff <bobduff@world.std.com> writes: > [...] I find it annoying, for example, that if I want decimal-formatted > integer, I can use 'Image, but if I want hexdecimal, I have to import > Text_IO (or write my own). Hexadecimal formatting has nothing directly > to do with I/O of character strings! This could be fixed by having separate packages offering all non IO/time services, and just renaming declarations inside the IO/time packages. The last point (renaming) is just implementation, it could be just left out of the standard and be put as a RM note, this is to say it shouldn't put a significant burden on implementors (move code and put a few renames) and should be 100% upward compatible for users. -- Laurent Guerby <guerby@acm.org> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calendar - leap seconds 2001-03-19 20:10 ` Laurent Guerby @ 2001-03-20 10:26 ` Nick Roberts 2001-03-20 19:23 ` Laurent Guerby 0 siblings, 1 reply; 11+ messages in thread From: Nick Roberts @ 2001-03-20 10:26 UTC (permalink / raw) "Laurent Guerby" <guerby@acm.org> wrote in message news:863dc9cyfj.fsf@acm.org... > Robert A Duff <bobduff@world.std.com> writes: > > [...] I find it annoying, for example, that if I want decimal-formatted > > integer, I can use 'Image, but if I want hexdecimal, I have to import > > Text_IO (or write my own). Hexadecimal formatting has nothing directly > > to do with I/O of character strings! > > This could be fixed by having separate packages offering all non > IO/time services, and just renaming declarations inside the IO/time > packages. The last point (renaming) is just implementation, it could > be just left out of the standard and be put as a RM note, this is to > say it shouldn't put a significant burden on implementors (move code > and put a few renames) and should be 100% upward compatible for users. Not exactly. It would not fix the fact that Ada.Calendar and Ada.Text_IO cannot be pure. On the other hand, it would be a nice fix to introduce two new standard, declared pure, packages Ada.Calendar_Conversions (with everything in Ada.Calendar except Clock, and perhaps more) and Ada.Text_Formatting (with everything in Ada.Text_IO except actual I/O operations). Implementations would then (almost) inevitably complete the corresponding declarations in Ada.Calendar and Ada.Text_IO by body renamings. -- Nick Roberts http://www.AdaOS.org ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calendar - leap seconds 2001-03-20 10:26 ` Nick Roberts @ 2001-03-20 19:23 ` Laurent Guerby 0 siblings, 0 replies; 11+ messages in thread From: Laurent Guerby @ 2001-03-20 19:23 UTC (permalink / raw) "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes: > "Laurent Guerby" <guerby@acm.org> wrote in message > > This could be fixed by having separate packages offering all non > > IO/time services, and just renaming declarations inside the IO/time > > packages. The last point (renaming) is just implementation, it could > > be just left out of the standard and be put as a RM note, this is to > > say it shouldn't put a significant burden on implementors (move code > > and put a few renames) and should be 100% upward compatible for users. > > Not exactly. It would not fix the fact that Ada.Calendar and Ada.Text_IO > cannot be pure. > > On the other hand, it would be a nice fix to introduce two new standard, > declared pure, packages Ada.Calendar_Conversions (with everything in > Ada.Calendar except Clock, and perhaps more) and Ada.Text_Formatting (with > everything in Ada.Text_IO except actual I/O operations). Implementations > would then (almost) inevitably complete the corresponding declarations in > Ada.Calendar and Ada.Text_IO by body renamings. I think we're saying the same thing here. Ada.Calendar and Ada.Text_IO cannot be pure for sure, but the new packages (I called them "separate package", you gave them explicit names) can be. -- Laurent Guerby <guerby@acm.org> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calendar - leap seconds 2001-03-18 15:53 ` Wilhelm Spickermann 2001-03-19 3:47 ` Nick Roberts @ 2001-03-20 11:34 ` Joseph P Vlietstra 2001-03-20 13:08 ` Wilhelm Spickermann 1 sibling, 1 reply; 11+ messages in thread From: Joseph P Vlietstra @ 2001-03-20 11:34 UTC (permalink / raw) On 17-Mar-01 singlespeeder wrote: > How do I handle leap seconds using Ada.Calendar as the subtype > Day_Duration doesn't have enough space for them? > > ARM 9.6(11): > subtype Day_Duration is Duration range 0.0 .. 86_400.0; Wilhelm Spickermann wrote: > But, will it help? Does Your operating system still support leap > seconds? AFAIK the BIG problem is, that most operating systems > no longer support leap seconds, as POSIX has switched to ignoring > them (<a time_t value of 536457599 shall correspond to "Wed Dec > 31 23:59:59 UTC 1986">). I wasn't able to login to the Austin group (joint Unix revision group) document site from home (I get paid to work on this at work), but I believe leap second support is still an open issue for the upcoming revision. The reason it's an open issue is that leap seconds may go away. From the IAU Commission 31 (Time) website (http://www.bipm.org/IAU31): > Since 1999, a number of organizations initiated a review on the > future of the UTC system (insertion of leap seconds between TAI > and UTC to keep |UT1-UTC|<0.9 s). The Consultative Committee for > Time and Frequency (CCTF) in 1999 discussed the matter and the > director of the BIPM sent letters to several international unions > and navigation agencies. The International Union of Radio Science > (URSI) created a WG, chaired by D.N. Matsakis (Commission 31 vice > president). In 2000 the International Telecommunications Union (ITU) > created a Special Rapporteur Group in the Working Party 7A, to study > the new Question ITU-R[TF-QQQ](still in draft form) on 'The future > of the UTC time scale'. The IAU 24th GA in 2000 passed Resolution B2 > to recommend the creation of a WG in collaboration with the URSI, > ITU, BIPM, IERS and navigation agencies. The leap second WG has not officially completed its work (and won't until the next IAU General Assembly meeting in 2002), but my guess is leap seconds will go away. Each time BIPM introduces a leap second there is a enormous amount of work involved. Systems tied to GPS receive the leap second update via the GPS almanac page, but many telemetry systems need their leap second kernel file updated or may even need a software update. Why go through all of this effort when civil timekeeping applications don't really care if UTC matches UT1 and most spacecraft/astronomical applications use the TAI, J2000, or the GPS linear timescale. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calendar - leap seconds 2001-03-20 11:34 ` Joseph P Vlietstra @ 2001-03-20 13:08 ` Wilhelm Spickermann 2001-03-31 14:07 ` Kent Paul Dolan 0 siblings, 1 reply; 11+ messages in thread From: Wilhelm Spickermann @ 2001-03-20 13:08 UTC (permalink / raw) To: comp.lang.ada On 20-Mar-01 Joseph P Vlietstra wrote: ... > believe leap second support is still an open issue for the upcoming > revision. The reason it's an open issue is that leap seconds may go > away. ... > or may even need a software update. Why go through all of this > effort > when civil timekeeping applications don't really care if UTC matches > UT1 and most spacecraft/astronomical applications use the TAI, J2000, > or the GPS linear timescale. Thank You very much! I hope the leap second insertion will be suspended for some decades. It should be possible then, to give an algorithm for leap second insertion for the next few hundred years... (But this will not remove the damage that has been done by creating a second definition of the timestamps given as time_t or struct timeval.) Wilhelm ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calendar - leap seconds 2001-03-20 13:08 ` Wilhelm Spickermann @ 2001-03-31 14:07 ` Kent Paul Dolan 2001-04-01 11:57 ` Simon Wright 0 siblings, 1 reply; 11+ messages in thread From: Kent Paul Dolan @ 2001-03-31 14:07 UTC (permalink / raw) Florian Weimer <fw@deneb.enyo.de> wrote: > Are there other pragmas with a similarly scoped effect? And into my head full blown lept lust for a programming language whose source code syntax was SGML based, like HTML or VML: <pragma pname = "foo" pparm_the_first = "bar"> <!-- lots of code --> <namespace nsname = "baz"> <!-- lots more code --> </namespace nsname = "baz"> </pragma pname = "foo"> which style would let comments be bound to the code they comment, provide easy support for pretty printing, and perhaps some other benefits that didn't enjoy that leap with the original idea. Now command line options would instead become style sheets! You have to be a power typist, and more than a bit mad, to love this kind of cruft, of course. The last line could be just: </pragma> but including the pname value allows better checking for matching scope delimiters. Just day-dreaming. Cheers! xanthian. -- Kent Paul Dolan <xanthian@well.com> -- Posted from smtp.well.com [208.178.101.27] via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Calendar - leap seconds 2001-03-31 14:07 ` Kent Paul Dolan @ 2001-04-01 11:57 ` Simon Wright 0 siblings, 0 replies; 11+ messages in thread From: Simon Wright @ 2001-04-01 11:57 UTC (permalink / raw) xanthian@well.com (Kent Paul Dolan) writes: > And into my head full blown lept lust for a programming language > whose source code syntax was SGML based, like HTML or VML: > > <pragma pname = "foo" pparm_the_first = "bar"> > > <!-- lots of code --> > > <namespace nsname = "baz"> > > <!-- lots more code --> > > </namespace nsname = "baz"> > > </pragma pname = "foo"> Have you come across XSLT? A tiny fragment from my not-formally-announced code framework generator at http://www.pushface.org/coldframe/ .. <!-- Generate the individual components of the class identifier or instance record. --> <xsl:template match="attribute" mode="instance-record-component"> <xsl:text> </xsl:text> <xsl:call-template name="attribute-name"/> <xsl:text> : </xsl:text> <xsl:call-template name="attribute-type"/> <xsl:if test="initial"> <xsl:text> := </xsl:text> <xsl:value-of select="initial"/> </xsl:if> <xsl:text>; </xsl:text> </xsl:template> Templates are slightly like subprograms; the outer one is a matcher, which finds all the <attribute> nodes in (the current subset of) the input document (but only operates in the "instance-record-component" mode), while the target of <xsl:call-template name="attribute-type"/> is only invoked when explicitly named .. <xsl:if test="initial"> succeeds if the current <attribute> element contains an <initial> element .. <xsl:value-of select="initial"/> outputs the content of said <initial> element .. loads more fun available! > The last line could be just: > > </pragma> I rather think this is required in SGML? not sure .. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2001-04-01 11:57 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-03-17 17:46 Calendar - leap seconds singlespeeder 2001-03-18 15:53 ` Wilhelm Spickermann 2001-03-19 3:47 ` Nick Roberts 2001-03-19 14:43 ` Robert A Duff 2001-03-19 20:10 ` Laurent Guerby 2001-03-20 10:26 ` Nick Roberts 2001-03-20 19:23 ` Laurent Guerby 2001-03-20 11:34 ` Joseph P Vlietstra 2001-03-20 13:08 ` Wilhelm Spickermann 2001-03-31 14:07 ` Kent Paul Dolan 2001-04-01 11:57 ` Simon Wright
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox