Re: C date package

[Geoff Bull <geoff@research.canon.com.au>]

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