I've got a question and a thought to stir the pot with.
Is there any problem with having negative values for the dates, or are
we talking about having only positive and increasing values?
It seems that providing a way to specify the base unit of time would be
helpful from a conceptual standpoint, even if it is a pain (and
understandably avoided when possible) to handle in code. So if you want
your unit of time to be 1 kyear or Myear or Gyear, you could work in
that basis (with a corresponding loss of precision).
On 8/24/2011 9:16 AM, John Caron wrote:
> On 8/24/2011 6:23 AM, Jonathan Gregory wrote:
>> Dear John
>>
>>> It seems to me it would be better to somehow denote the "epoch"
>>> seperately, because its kind of silly keeping track of # millisecs
>>> between two dates separated by 50 million years. plus its hard.
>>>
>>> what about:
>>>
>>> "01-01-01 12:00 epoch 50m BCE"
>>>
>>> where the "epoch 50m BCE" is probably just carried along in the
>>> string representation of the date.
>> I agree that that's a sensible way to do it for dates which are
>> separated
>> by relatively short periods in an epoch which is a long time ago.
>> However
>> it could be useful if the epoch wasn't just a string. If it was a
>> longinteger
>> number of calendar years (relative to the normal year 1) you would be
>> able
>> to interconvert dates expressed relative to different epochs. That
>> is, you
>> could tell that 10 calendar Myears since 01-01-01 epoch 20M BCE means
>> the
>> same as 0 calendar years since 01-01-01 epoch 10M BCE. This
>> conversion would
>> be accurate provided the time unit in calendar years is stored as an
>> integer.
>> Accuracy is lost if it is turned into floating-point milliseconds, I
>> suppose.
>
> I agree we should be able to calculate intervals between epochs.
> calendar years would also be my first choice as the unit of this.
>
> since im going to propose some grammar that we will be stuck with for
> the next 50m years, id like your (or anyone's) thoughts on the wording.
>
> currently i have thought of
>
> "01-01-01 12:00 epoch 50m BCE"
> "01-01-01 12:00 reference 50m BCE"
>
>
> but im open to anything
>
>>
>> The other kind of example of palaeoclimate is the
>> one where large periods of time are spanned by the time axis e.g. if you
>> had a timeseries whose time axis spanned all the geological periods
>> since
>> 600 Myear ago. (That would probably not be from a GCM! - but it could
>> be from
>> geological data or other Earth system models.) That sort of axis
>> would like
>> to use units of calendar Myear and they need to be stored accurately.
>
> some possibilities that occur to me (not yet sure whats feasible in
> parser):
>
> "50 calendar Myears since 1980-01-01"
>
> "50 Myears since 1980-01-01" (Myears == million calendar years)
>
> "50 Myears" (assume reference is 0 CE)
>
>>
>> About the multiples of calendar units: You have said they should be
>> integers.
>> However, perhaps fractions could be rather useful. For example, we
>> have the
>> recurrent question of where the time coordinate should be positioned
>> in the
>> interval if the data actually applies to the interval rather than the
>> instant.
>> It's a bit arbitrary and the usual advice is to put it in the middle.
>> For this
>> it would be convenient to have time-bounds for a cell of e.g. "1
>> calendar month
>> since reference" and "2 calendar months since reference", with the
>> time-coord
>> of "1.5 calendar months since reference".
>
> it seems like a more informative coordinate value would be, eg "Feb
> 2001" when the bounds are [1,2] calendar months since 2001-01-01 ?
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Jim Biard
Government Contractor, STG Inc.
Remote Sensing and Applications Division (RSAD)
National Climatic Data Center
151 Patton Ave.
Asheville, NC 28801-5001
jim.biard at noaa.gov
828-271-4900
Received on Wed Aug 24 2011 - 07:36:18 BST
