paulr@sequent.UUCP (Paul Reger) (08/29/89)
I was wondering if any extensions to CALENDAR were planned regarding:
1. Timezones. Perhaps implement the 'universal time' (whatever it
is called, the time that airlines, and satellites use) into the
package. Or maybe have information that will name the 24 time zones
in the world and have a function to return what the name of the local
time is.
2. Daylight savings time. This varies from Country to Country,
but it would still be useful for implementations to give this type of
information. (I do not know precisely what I am suggesting an
implementation do with this information, but it would be useful
nonetheless.)
Just curious. Time seems to be a flakey thing to measure especially
with all of the changes that go on...dik@cwi.nl (Dik T. Winter) (08/29/89)
In article <20800@sequent.UUCP> paulr@sequent.UUCP (Paul Reger) writes: > I was wondering if any extensions to CALENDAR were planned regarding: > > 1. Timezones. Perhaps implement the 'universal time' (whatever it > is called, the time that airlines, and satellites use) into the > package. Or maybe have information that will name the 24 time zones > in the world and have a function to return what the name of the local > time is. Yup. Implementing UTC looks fine. But although there are 24 timezones according to the US military rules (zones A-Z with some letters omitted), some countries do not conform to this and their time differs not an integral number of hours from UTC (some parts of Canada for instance). Better would be a function that returns the difference of local time and UTC. > > 2. Daylight savings time. This varies from Country to Country, > but it would still be useful for implementations to give this type of > information. (I do not know precisely what I am suggesting an > implementation do with this information, but it would be useful > nonetheless.) Also here, DST is very hairy. Implement a function that returns a boolean that tells whether DST is in effect, and also tells the difference between DST and normal time (it has not always been 1 hour everywhere, so it need not be in the future). An excellent implementation of time routines in C for the Unix system is done by ADO (A. D. Olson), and can be found in the later implementations of BSD Unix, and also in many sources archives. It is public domain. It is not possible to do this portably in Ada, because information regarding DST should be kept in (easy updatable) files because there are a lot of countries with no fixed rules. -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax
cjsv@cs.adfa.oz.au (Christopher J S Vance) (08/31/89)
In article <20800@sequent.UUCP> paulr@sequent.UUCP (Paul Reger) writes:
.> package. Or maybe have information that will name the 24 time zones
.> in the world and have a function to return what the name of the local
.> time is.
-12 hours ... +12 hours gives 25 time zones. Now add all those places
where the difference from UTC is not an integral number of hours. How
many now? Does Saudi Arabia still use solar time (midnight at sunset?)
-- that one varies a lot. The ISO standard `name' of my timezone is
`+1000', meaning 10 hours ahead of UTC, but other parts of Australia
(including external territories) are on +0630, +0700, +0800, +0930,
+1030 and +1130. And there are even more time zones in summer, because
some of the country changes, while the rest doesn't.
If you want to use parochial names for timezones like PST, PDT, etc.,
then you've made it impossible for Ada to work outside USA. Does `BST'
mean Bering Standard Time (if it still exists?) or British Summer Time?
Just because Bering Time was/is used in Alaska doesn't mean all of your
NATO places in the UK should get the time wrong all summer, does it?
Using ISO names makes it much easier for your package to work
world-wide. But you still have to include the minutes, not just hours.
And it's not even tied to the English language for time zones.
.> 2. Daylight savings time. This varies from Country to Country,
.> but it would still be useful for implementations to give this type of
.> information. (I do not know precisely what I am suggesting an
.> implementation do with this information, but it would be useful
.> nonetheless.)
And from part-to-part of the same country. Parts of Australia do not
have DST, and there's no guarantee those that do will do so at the same
time.
A while back, a package was posted to provide exactly the sort of thing
you want, but it was in C for Unix. Maybe Ada can learn from the rest
of the world.