[-- Attachment #1: Type: text/plain, Size: 1575 bytes --] I have been pleased to learn that I can add / subtract hours in org-table to shift time zones. I am making tables of lunar/solar parameters relevant to tides. Org-table is a convenient way to enter data in a tabular format that can be printed via LaTeX. So each year, for several time zones, I enter these times by hand. It's very, very easy, I have learned, to collect all of these times (at most, maybe 12 per month) for UTC, and add or subtract to generate a column of times for a new time zone. Very Slick! Except that when I add, for example. 09:00 to 23:33, I guess it is pretty obvious what is going to happen: it would be the same day, but at 32:33 !! I have tripped up on trying to test for whether the sum is greater than or equal to 24:00, and then doing something interesting with it. It's actually pretty easy to go through all the months and find the exceptions, and make manual changes. But, as I usually have done, I would rather spend a few hours coming up with some programmatic method for making this work automatically! The other problem is the change of the day. I suppose I could use 0, 1, 2... for Sunday, Monday, Tuesday... (I am living in the United States). Has someone solved this problem? Thank you, Alan Davis -- "This ignorance about the limits of the earth's ability to absorb pollutants should be reason enough for caution in the release of polluting substances." ---Meadows et al. 1972. Limits to Growth <https://www.dartmouth.edu/~library/digital/publishing/meadows/ltg/>. (p. 81) [-- Attachment #2: Type: text/html, Size: 2323 bytes --]
Alan E. Davis <lngndvs@gmail.com> writes:
> I have been pleased to learn that I can add / subtract hours in org-table
> to shift time zones. I am making tables of lunar/solar parameters
> relevant to tides. Org-table is a convenient way to enter data in a
> tabular format that can be printed via LaTeX. So each year, for several
> time zones, I enter these times by hand.
>
> It's very, very easy, I have learned, to collect all of these times (at
> most, maybe 12 per month) for UTC, and add or subtract to generate a column
> of times for a new time zone. Very Slick!
>
> Except that when I add, for example. 09:00 to 23:33, I guess it is pretty
> obvious what is going to happen: it would be the same day, but at 32:33 !!
>
> I have tripped up on trying to test for whether the sum is greater than or
> equal to 24:00, and then doing something interesting with it. It's
> actually pretty easy to go through all the months and find the exceptions,
> and make manual changes. But, as I usually have done, I would rather spend
> a few hours coming up with some programmatic method for making this work
> automatically!
>
> The other problem is the change of the day. I suppose I could use 0, 1,
> 2... for Sunday, Monday, Tuesday... (I am living in the United States).
>
> Has someone solved this problem?
>
Org tables support formulas which use the Emacs 'calc' program. Calc has
pretty good support for adding, subtracting, multiplying and otherwise
manipulating dates and times (this is how the org clocktable works). It
should be pretty straight forward to have a column of date + time
values, a time offset representing a timezone and a 3rd column which is
the new date/time after applying the offset. Have a look at the secton
in the org manual on table formulas and the calc manual in info.
--
Tim Cross
[-- Attachment #1: Type: text/plain, Size: 3397 bytes --] I am close to throwing in the towel. Thank you for the suggestion. Several problems have been encountered. I wonder whether I understand this tool at all. If I subtract 10:00 from 08:46, the answer given is -01:14. I used #+TBLFM: $6=$4+$5;U, as follows (please forgive the formatting): | Phenom | Date | DoW | UTC | Hrs | ChST | | |--------+--------+-----+-------+--------+--------+---| | ApoG | 22 | Fr | 06:44 | -10:00 | -03:16 | | |--------+--------+-----+-------+--------+--------+---| #+TBLFM: $6=$4+$5;U When I add 10:00, I think the values are sensible: 21:45 + 10:00 = 31:45. Another problem was in trying to use an inactive org timestamp. It was not straightforward to add or subtract N hours (say, 08:00). This it a thornier problem than I had envisioned, anyway, because in locale with time zones, the conversion factor will change at some point DURING the month. Perhaps there is a calc procedure to convert time zones that will take into account the system's knowledge of the timezones as well as changes to/from Daylight Time. For now, On Wed, Dec 9, 2020 at 3:40 AM Tim Cross <theophilusx@gmail.com> wrote: > > Alan E. Davis <lngndvs@gmail.com> writes: > > > I have been pleased to learn that I can add / subtract hours in org-table > > to shift time zones. I am making tables of lunar/solar parameters > > relevant to tides. Org-table is a convenient way to enter data in a > > tabular format that can be printed via LaTeX. So each year, for several > > time zones, I enter these times by hand. > > > > It's very, very easy, I have learned, to collect all of these times (at > > most, maybe 12 per month) for UTC, and add or subtract to generate a > column > > of times for a new time zone. Very Slick! > > > > Except that when I add, for example. 09:00 to 23:33, I guess it is pretty > > obvious what is going to happen: it would be the same day, but at 32:33 > !! > > > > I have tripped up on trying to test for whether the sum is greater than > or > > equal to 24:00, and then doing something interesting with it. It's > > actually pretty easy to go through all the months and find the > exceptions, > > and make manual changes. But, as I usually have done, I would rather > spend > > a few hours coming up with some programmatic method for making this work > > automatically! > > > > The other problem is the change of the day. I suppose I could use 0, 1, > > 2... for Sunday, Monday, Tuesday... (I am living in the United States). > > > > Has someone solved this problem? > > > > Org tables support formulas which use the Emacs 'calc' program. Calc has > pretty good support for adding, subtracting, multiplying and otherwise > manipulating dates and times (this is how the org clocktable works). It > should be pretty straight forward to have a column of date + time > values, a time offset representing a timezone and a 3rd column which is > the new date/time after applying the offset. Have a look at the secton > in the org manual on table formulas and the calc manual in info. > > -- > Tim Cross > > -- "This ignorance about the limits of the earth's ability to absorb pollutants should be reason enough for caution in the release of polluting substances." ---Meadows et al. 1972. Limits to Growth <https://www.dartmouth.edu/~library/digital/publishing/meadows/ltg/>. (p. 81) [-- Attachment #2: Type: text/html, Size: 4683 bytes --]
Alan E. Davis <lngndvs@gmail.com> writes: > I am close to throwing in the towel. > > Thank you for the suggestion. Several problems have been encountered. I > wonder whether I understand this tool at all. If I subtract 10:00 from > 08:46, the answer given is -01:14. I used #+TBLFM: $6=$4+$5;U, as follows > (please forgive the formatting): > > | Phenom | Date | DoW | UTC | Hrs | ChST | | > |--------+--------+-----+-------+--------+--------+---| > | ApoG | 22 | Fr | 06:44 | -10:00 | -03:16 | | > |--------+--------+-----+-------+--------+--------+---| > #+TBLFM: $6=$4+$5;U > > When I add 10:00, I think the values are sensible: 21:45 + 10:00 = 31:45. > What did you expect for 8:46 - 10:00? Looks correct to me or were you expecting 22:46 (24:00 - 01:14)? This would mean 21:45 + 10:00 should be 07:45. I think when your working with times like this, you need to include the date to help make sense of the result. > Another problem was in trying to use an inactive org timestamp. It was not > straightforward to add or subtract N hours (say, 08:00). > You probably need to use the ort-timestamp-to-time and org-timestmap-from-time to convert the timestamp to a 'time' value (I suspect it uses either ms or sec since epoch as the base). Convert to time, add/subtract offset, convert back to inactive timestamp. > This it a thornier problem than I had envisioned, anyway, because in locale > with time zones, the conversion factor will change at some point DURING the > month. > > Perhaps there is a calc procedure to convert time zones that will take into > account the system's knowledge of the timezones as well as changes to/from > Daylight Time. > > For now, > The big pain with working on time and timezones is the daylight savings complication. This is really tricky because the start and end date tend to be influenced by politics (I've seen DST change because of some event, like Olympic games or to coincide with easter holiday etc) and some states/geographies may decide not to use DST while others do (for example, in Australia, some states have DST and some don't - so for half the year, all the eastern states have the same timezone, but then for half the year, 3 are the same and one is different). There is some information in the calendar section of the emacs manual which might be useful and it does have a section on working with DST (I've not read it). In addition to the org mode functions to manipulate dates and times, there are also various elisp functions you can also use. It is a thorny problem because of the edge cases, but the basic functions are all there. Your best bet is to probably write a function which accepts a full date+time and UTC offset in minutes which returns a new date+time value and then call that function in your table formula. -- Tim Cross
[-- Attachment #1: Type: text/plain, Size: 4171 bytes --] Thank you for taking the time to answer my questions, TIm. For my purposes, it's maybe easier to just bite the bullet and do it in my head. I had hoped that subtracting 10 hours from 06:44 UTC would get me at least -04:44. I can easily make the change to correct clock time (19:44) and change the day name. I was duplicating the work of looking up the time in XEphem, the ephemeris program I am using, which requires some amount of fiddling---solving for the time of max/min lunar declination. It will save hours of time to use org-mode's spreadsheet to add/subtract the Timezone offsets. As it turns out, this is not a straightforward procedure. Also, as you point out, this process is even less convenient due to inconsistencies in the political realm. I appreciate your comments. Alan Davis On Thu, Dec 10, 2020 at 12:17 PM Tim Cross <theophilusx@gmail.com> wrote: > > Alan E. Davis <lngndvs@gmail.com> writes: > > > I am close to throwing in the towel. > > > > Thank you for the suggestion. Several problems have been encountered. I > > wonder whether I understand this tool at all. If I subtract 10:00 from > > 08:46, the answer given is -01:14. I used #+TBLFM: $6=$4+$5;U, as > follows > > (please forgive the formatting): > > > > | Phenom | Date | DoW | UTC | Hrs | ChST | | > > |--------+--------+-----+-------+--------+--------+---| > > | ApoG | 22 | Fr | 06:44 | -10:00 | -03:16 | | > > |--------+--------+-----+-------+--------+--------+---| > > #+TBLFM: $6=$4+$5;U > > > > When I add 10:00, I think the values are sensible: 21:45 + 10:00 = 31:45. > > > > What did you expect for 8:46 - 10:00? Looks correct to me or were you > expecting 22:46 (24:00 - 01:14)? This would mean 21:45 + 10:00 should be > 07:45. I think when your working with times like this, you need to > include the date to help make sense of the result. > > > Another problem was in trying to use an inactive org timestamp. It was > not > > straightforward to add or subtract N hours (say, 08:00). > > > > You probably need to use the ort-timestamp-to-time and > org-timestmap-from-time to convert the timestamp to a 'time' value (I > suspect it uses either ms or sec since epoch as the base). Convert to > time, add/subtract offset, convert back to inactive timestamp. > > > This it a thornier problem than I had envisioned, anyway, because in > locale > > with time zones, the conversion factor will change at some point DURING > the > > month. > > > > Perhaps there is a calc procedure to convert time zones that will take > into > > account the system's knowledge of the timezones as well as changes > to/from > > Daylight Time. > > > > For now, > > > > The big pain with working on time and timezones is the daylight savings > complication. This is really tricky because the start and end date tend > to be influenced by politics (I've seen DST change because of some > event, like Olympic games or to coincide with easter holiday etc) and > some states/geographies may decide not to use DST while others do (for > example, in Australia, some states have DST and some don't - so for half > the year, all the eastern states have the same timezone, but then for > half the year, 3 are the same and one is different). > > There is some information in the calendar section of the emacs manual > which might be useful and it does have a section on working with DST > (I've not read it). In addition to the org mode functions to manipulate > dates and times, there are also various elisp functions you can also > use. > > It is a thorny problem because of the edge cases, but the basic > functions are all there. Your best bet is to probably write a function > which accepts a full date+time and UTC offset in minutes which returns a > new date+time value and then call that function in your table formula. > -- > Tim Cross > -- "This ignorance about the limits of the earth's ability to absorb pollutants should be reason enough for caution in the release of polluting substances." ---Meadows et al. 1972. Limits to Growth <https://www.dartmouth.edu/~library/digital/publishing/meadows/ltg/>. (p. 81) [-- Attachment #2: Type: text/html, Size: 5463 bytes --]
2020-12-11 Alan E. Davis wrote:
>
> I had hoped that subtracting 10 hours from 06:44 UTC would get me at
> least -04:44.
I am in doubts how to present negative time correctly. Having in mind
wall clocks with hands, your expectation has some sense.
I think, the source of confusion is that you are trying to use
facilities intended for TimeInterval + TimeInterval arithmetic, where
TimeInterval denotes a type. Actually you need to compute Time +
TimeInterval. Sorry, I am unaware if Emacs provides proper functions.
There are a lot of subtle issues with time-related operations, but most
of DST complications pointed out by Tim could be handled with IANA
(Olson) DB for time zones, on Linux it is almost always installed as
tzdata package and is getting regular updates. It is rather precise and
contains history of DST and other transitions. If people complains on
incorrect results, usually they have wrong timezone set on their computers.
For astronomy the best representation should be timestamp (seconds since
epoch) converted to local date time when necessary. Unsure concerning
leap seconds.
Human-related future events mostly should be stored as date + local time
+ label of administrative region that allows to get time zone ID (namely
ID, not offset from UTC). Time offset could be changed after event has
been planned, time zone could be split into several ones with distinct
offsets.
- LocalTime + TimeInterval operation could give incorrect result unless
LocalTime is augmented with date and TimeZone, the latter is the history
of transitions.
- TimeZone (e.g. Europe/Berlin) as full transition history is not the
same as TimeOffset at particular moment (+0100).
Carefully choose storage format:
- just Date e.g. for date of birth (adding time or time zone could
distort results),
- Date + LocalTime + Place for planned events
- Timestamp for most events in past. Use it for future if local time is
irrelevant, astronomical events is an example.
Conversion to local time could evolve due to administrative decisions.
Examples when Olson DB is not enough and additional negotiations or
justifications are necessary:
- (March, 31) - (1 month)
- Conversion from Date + LocalTime to Timestamp around time transition
when non-existing or ambiguous local time is possible.
[-- Attachment #1: Type: text/plain, Size: 2601 bytes --] Maxim: Thank for the clear explanation. My little problem seems to require a super steam hammer. Your insights are most helpful. Alan On Fri, Dec 11, 2020, 07:46 Maxim Nikulin <manikulin@gmail.com> wrote: > 2020-12-11 Alan E. Davis wrote: > > > > I had hoped that subtracting 10 hours from 06:44 UTC would get me at > > least -04:44. > > I am in doubts how to present negative time correctly. Having in mind > wall clocks with hands, your expectation has some sense. > > I think, the source of confusion is that you are trying to use > facilities intended for TimeInterval + TimeInterval arithmetic, where > TimeInterval denotes a type. Actually you need to compute Time + > TimeInterval. Sorry, I am unaware if Emacs provides proper functions. > > There are a lot of subtle issues with time-related operations, but most > of DST complications pointed out by Tim could be handled with IANA > (Olson) DB for time zones, on Linux it is almost always installed as > tzdata package and is getting regular updates. It is rather precise and > contains history of DST and other transitions. If people complains on > incorrect results, usually they have wrong timezone set on their computers. > > For astronomy the best representation should be timestamp (seconds since > epoch) converted to local date time when necessary. Unsure concerning > leap seconds. > > Human-related future events mostly should be stored as date + local time > + label of administrative region that allows to get time zone ID (namely > ID, not offset from UTC). Time offset could be changed after event has > been planned, time zone could be split into several ones with distinct > offsets. > > - LocalTime + TimeInterval operation could give incorrect result unless > LocalTime is augmented with date and TimeZone, the latter is the history > of transitions. > - TimeZone (e.g. Europe/Berlin) as full transition history is not the > same as TimeOffset at particular moment (+0100). > > Carefully choose storage format: > - just Date e.g. for date of birth (adding time or time zone could > distort results), > - Date + LocalTime + Place for planned events > - Timestamp for most events in past. Use it for future if local time is > irrelevant, astronomical events is an example. > > Conversion to local time could evolve due to administrative decisions. > > Examples when Olson DB is not enough and additional negotiations or > justifications are necessary: > > - (March, 31) - (1 month) > - Conversion from Date + LocalTime to Timestamp around time transition > when non-existing or ambiguous local time is possible. > > > [-- Attachment #2: Type: text/html, Size: 3213 bytes --]
* Maxim Nikulin <manikulin@gmail.com> [2020-12-11 18:45]:
> 2020-12-11 Alan E. Davis wrote:
> >
> > I had hoped that subtracting 10 hours from 06:44 UTC would get me at
> > least -04:44.
>
> I am in doubts how to present negative time correctly. Having in mind wall
> clocks with hands, your expectation has some sense.
>
> I think, the source of confusion is that you are trying to use facilities
> intended for TimeInterval + TimeInterval arithmetic, where TimeInterval
> denotes a type. Actually you need to compute Time + TimeInterval. Sorry, I
> am unaware if Emacs provides proper functions.
>
> There are a lot of subtle issues with time-related operations, but most of
> DST complications pointed out by Tim could be handled with IANA (Olson) DB
> for time zones, on Linux it is almost always installed as tzdata package and
> is getting regular updates. It is rather precise and contains history of DST
> and other transitions. If people complains on incorrect results, usually
> they have wrong timezone set on their computers.
>
> For astronomy the best representation should be timestamp (seconds since
> epoch) converted to local date time when necessary. Unsure concerning leap
> seconds.
>
> Human-related future events mostly should be stored as date + local time +
> label of administrative region that allows to get time zone ID (namely ID,
> not offset from UTC). Time offset could be changed after event has been
> planned, time zone could be split into several ones with distinct offsets.
>
> - LocalTime + TimeInterval operation could give incorrect result unless
> LocalTime is augmented with date and TimeZone, the latter is the history of
> transitions.
> - TimeZone (e.g. Europe/Berlin) as full transition history is not the same
> as TimeOffset at particular moment (+0100).
Let me just comment that PostgreSQL database has date/time types such
as:
TIMESTAMP WITHOUT TIME ZONE and
TIMESTAMP WITH TIME ZONE
but all of them are stored without time zone, the difference being
that "WITH TIME ZONE" would only be displayed with specific time
zone.
Same approach can be used in other time storages, just store it as
UTC, display it as you wish.
Jean
2020-12-12 Alan E. Davis wrote:
>
> Thank for the clear explanation. My little problem seems to require a
> super steam hammer. Your insights are most helpful.
You do not need a steam hammer. There are a number of tools around. Some
of hammers however could not deal with all nails.
Even "date" util could be used to convert between timestamps and human
readable representation, between timezones. It could even do some arithmetic
date --utc -d @1234567890
Fri Feb 13 23:31:30 UTC 2009
date -d 'now' +%s
1607787784
date -d 'now +10hours' +%s
1607823786
TZ=America/New_York date -d "@`TZ=Europe/Berlin date -d '2020-11-10
09:08:07 +10hours' '+%s'`"
Mon Nov 9 19:08:07 EST 2020
In my opinion, org mode is too rigid in respect to timestamp format.
Sometimes I would prefer to specify timestamps with timezone.
Well known example of idiosyncrasy of particular applications.
Timestamps in xls files are represented by floating point numbers,
namely days since 1 Jan 1900, fractional part is time. Unfortunately
1900 is not a leap year, so to avoid unnecessary complications of code
and keep memory footprint small, on Macs epoch starts in 1904, on
windows year 1900 has Feb, 29...
Maxim Nikulin <manikulin@gmail.com> writes:
> 2020-12-12 Alan E. Davis wrote:
>>
>> Thank for the clear explanation. My little problem seems to require a
>> super steam hammer. Your insights are most helpful.
>
> In my opinion, org mode is too rigid in respect to timestamp format.
> Sometimes I would prefer to specify timestamps with timezone.
>
> Well known example of idiosyncrasy of particular applications.
> Timestamps in xls files are represented by floating point numbers,
> namely days since 1 Jan 1900, fractional part is time. Unfortunately
> 1900 is not a leap year, so to avoid unnecessary complications of code
> and keep memory footprint small, on Macs epoch starts in 1904, on
> windows year 1900 has Feb, 29...
Although there are likely some dark corners where bugs can be found, I
think you could probably add timezone data to org timestamps by changing
the default format strings. Org also uses an 'internal' 'time' value to
represent timestamps which are then converted to the required format
using these format strings.
What is possibly missing is an easy way to specify a time zone when
creating a timestamp. I suspect it will default to whatever the local
system tz is and I don't think there is any convenient way to change tz
values like there is for the other timestamp components.
--
Tim Cross
[-- Attachment #1: Type: text/plain, Size: 1941 bytes --] Thank for the ideas. The 'date' command examples look interesting. I think R would not be too unwieldy as a hammer here. My use case is a humble one: just take a several clock times in HH:MM format (utc) and adjust to another timezone by adding or subtracting the relevant number of hours. The day of week is not important; i will have to deal with it. I did imagine a conditional subtraction by adding of subtracting 24:00 as needed. Much thanks for the advice. Alan On Sat, Dec 12, 2020, 15:00 Tim Cross <theophilusx@gmail.com> wrote: > > Maxim Nikulin <manikulin@gmail.com> writes: > > > 2020-12-12 Alan E. Davis wrote: > >> > >> Thank for the clear explanation. My little problem seems to require a > >> super steam hammer. Your insights are most helpful. > > > > In my opinion, org mode is too rigid in respect to timestamp format. > > Sometimes I would prefer to specify timestamps with timezone. > > > > Well known example of idiosyncrasy of particular applications. > > Timestamps in xls files are represented by floating point numbers, > > namely days since 1 Jan 1900, fractional part is time. Unfortunately > > 1900 is not a leap year, so to avoid unnecessary complications of code > > and keep memory footprint small, on Macs epoch starts in 1904, on > > windows year 1900 has Feb, 29... > > Although there are likely some dark corners where bugs can be found, I > think you could probably add timezone data to org timestamps by changing > the default format strings. Org also uses an 'internal' 'time' value to > represent timestamps which are then converted to the required format > using these format strings. > > What is possibly missing is an easy way to specify a time zone when > creating a timestamp. I suspect it will default to whatever the local > system tz is and I don't think there is any convenient way to change tz > values like there is for the other timestamp components. > > -- > Tim Cross > > [-- Attachment #2: Type: text/html, Size: 2699 bytes --]
2020-12-13 Alan E. Davis wrote: > > I think R would not be too unwieldy as a hammer here. My use case is a > humble one: just take a several clock times in HH:MM format (utc) and > adjust to another timezone by adding or subtracting the relevant number > of hours. The day of week is not important; i will have to deal with > it. I did imagine a conditional subtraction by adding of subtracting > 24:00 as needed. Likely your approach is suitable for you and you could ignore my comments. I just live in a city having longitude that should be (and it was) the border between time zones, so majority do not like any decision. Since cancellation of DST 10 years ago, local time has been shifted 2 times... To get time offset for some timezone, it is necessary to specify timestamp, so a date is required in addition to time. Namely day of week is mostly irrelevant. Time transitions are usually arranged at night when most of people are not active. Astronomers is a different case, that is why their chance to face a timezone bug is higher. When operations with arbitrary time zones are not required and a process could be run with TZ variable set to desired time zone, libc functions should work correctly. I have not tried elisp functions https://www.gnu.org/software/emacs/manual/html_node/elisp/Time-Zone-Rules.html A bookmark for those who still hopes to avoid complications with time-related operations Falsehoods programmers believe about time https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
[-- Attachment #1: Type: text/plain, Size: 2136 bytes --] Maxim: Both of these links, like your comments, are incredibly useful. Happy New Year (however you may measure that thing) On Sun, Dec 13, 2020 at 9:05 AM Maxim Nikulin <manikulin@gmail.com> wrote: > 2020-12-13 Alan E. Davis wrote: > > > > I think R would not be too unwieldy as a hammer here. My use case is a > > humble one: just take a several clock times in HH:MM format (utc) and > > adjust to another timezone by adding or subtracting the relevant number > > of hours. The day of week is not important; i will have to deal with > > it. I did imagine a conditional subtraction by adding of subtracting > > 24:00 as needed. > > Likely your approach is suitable for you and you could ignore my > comments. I just live in a city having longitude that should be (and it > was) the border between time zones, so majority do not like any > decision. Since cancellation of DST 10 years ago, local time has been > shifted 2 times... > > To get time offset for some timezone, it is necessary to specify > timestamp, so a date is required in addition to time. Namely day of week > is mostly irrelevant. > > Time transitions are usually arranged at night when most of people are > not active. Astronomers is a different case, that is why their chance to > face a timezone bug is higher. > > When operations with arbitrary time zones are not required and a process > could be run with TZ variable set to desired time zone, libc functions > should work correctly. I have not tried elisp functions > > https://www.gnu.org/software/emacs/manual/html_node/elisp/Time-Zone-Rules.html > > A bookmark for those who still hopes to avoid complications with > time-related operations > > Falsehoods programmers believe about time > > https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time > > > -- "This ignorance about the limits of the earth's ability to absorb pollutants should be reason enough for caution in the release of polluting substances." ---Meadows et al. 1972. Limits to Growth <https://www.dartmouth.edu/~library/digital/publishing/meadows/ltg/>. (p. 81) [-- Attachment #2: Type: text/html, Size: 3347 bytes --]