Campbell Time

[Tim Bergsma]

Cambell programming language now gives you a little flexibility on what
to do with midnight (did they always?).  I recently switched my hourly
summaries to be output as 1-24 hours rather than "zeroPrevious"-23
hours.

Tim.

> Peter McCartney wrote:
> 
> We convert the campbell fields into a datetime field and include both
> types into our database. Many of our researchers have existing scripts
> to use what campbell calls "julian day" and julian hour. It gets a bit
> tricky around midnight, since the cambell's hour field goes from 0-23
> and in the date time field 0000 hours is 1200 hours the previous day.
> 
> Since they come as two different fields, we don't encounter the
> YYYYDDD format in a single attribute, although I understand there are
> many alternate ascii formats you can configure the thing to use.
> 
> Peter McCartney (peter.mccartney at asu.edu)
> Center for Environmental-Studies
> Arizona State University
> 
> 
> -----Original Message-----
> From: Tim Bergsma [mailto:tbergsma at kbs.msu.edu]
> Sent: Monday, March 24, 2003 7:51 AM
> To: Scott Chapal
> Cc: Peter McCartney; eml-dev at ecoinformatics.org
> Subject: Re: Julian Date format -- interval not dateTime (my thought)
> 
> Campell Scientific dataloggers, the workhorses of weather data,
> normally record date with two fields:  year and day-of-year.  If you
> want to document the  raw data file, you're stuck with that.  (I guess
> technically you could say date wasn't recorded.) Most of us probably
> transform year/day of year to generate a 'real' date, at least for
> 'value-added' products.
> 
> Incidentally, I discovered by accident a function in MSAccess called
> DateSerial(year,month,day).  At first it doesn't look very helpful,
> but if you hard-code the month as 1, you can put any positive integer
> at all for day, and get a valid date in return!  For instance, the
> 365th day of January 2003 is 12-31-2003.
> 
> So back to the point, I wouldn't be at all surprised if YYYYDDD is
> ubiquitous, as a merge of the standard Campbell fields.  The issue is
> likely to come up for others.  If someone (Scott) finds a nice way of
> handling it, I favor the R&D strategy (rob and duplicate).
> 
> Tim.
> 
> Scott Chapal wrote:
> >
> > Peter McCartney <peter.mccartney at asu.edu> writes:
> >
> > > julian days would be ratio.
> >
> >  day-of-year ? :)
> > >
> > > YYYYDD would NOT be ordinal - it would be an odd representation of
> 
> > > dateTime that would be really confusing and not supported by most
> > > processing systems. Its like trying to write 111 deg, 1 min, 1
> > > second as 111 deg, 61 seconds - in priciple, its correct, but why
> > > would you do it?
> >
> > I wouldn't.
> >
> > But I have seen dates encoded that way.  I'm guessing by
> data-loggers
> > that were attempting to conserve bits.?  But then again, I've seen
> > dates formatted a lot of silly ways.
> >
> > dateTime non-Standard YYYYDDD - Year-and-day-of-year
> >
> > -Scott
> >
> > > Peter McCartney(peter.mccartney at asu.edu)
> > > Center for Environmental Studies
> > > Arizona State University
> > >
> > >
> > > -----Original Message-----
> > > From: Tim Bergsma [mailto:tbergsma at kbs.msu.edu]
> > > Sent: Thursday, March 20, 2003 11:51 AM
> > > To: Scott Chapal
> > > Cc: eml-dev at ecoinformatics.org; Henshaw, Don; Spycher, Gody
> > > Subject: Re: Julian Date format -- interval not dateTime (my
> > > thought)
> > >
> > >
> > > Scott,
> > >
> > > Did anyone reply to this yet?  I think the answers are yes and yes
> 
> > > (and yes), but I'm no expert yet on date formats (conveniently, I
> > > was out of the country when that part of EML got finalized).
> > >
> > > Tim.
> > >
> > > Scott Chapal wrote:
> > > >
> > > > So..
> > > >
> > > > "Day of Year" 1-365(6)
> > > >
> > > > measurementScale: RATIO
> > > > unit: nominalDay
> > > >
> > > > And, YYYYDDD would be ORDINAL (and a poor choice of date
> format)?
> > > >
> > > > -Scott
> > > >
> > > > Matt Jones <jones at nceas.ucsb.edu> writes:
> > > >
> > > > > I agree.  We created the unit 'nominalDay' precisely for this
> > > > > purpose. It represents an integer number of days.
> > > > >
> > > > > Matt
> > > > >
> > > > > Tim Bergsma wrote:
> > > > > > Scott,
> > > > > > I was also wondering about "this advice".  I was taught
> > > > > > somewhere not to
> > > > >
> > > > > > confuse Julian Day with day-of-year.  I use day-of-year, but
> I
> > > > > > don't really know what Julian Day is, and therefore hesitate
> 
> > > > > > to say too much. With regard to "saying that something takes
> 
> > > > > > 200 Julian Days", this is
> > > > >
> > > > > > clearly the same concept as eml dictionary unit nominalDay.
> > > > > > Tim.
> > > >
> > > > --
> > > > \SEC
> > > > _______________________________________________
> > > > eml-dev mailing list
> > > > eml-dev at ecoinformatics.org
> > > > http://www.ecoinformatics.org/mailman/listinfo/eml-dev
> > >
> > > --
> > > Tim Bergsma
> > > LTER Information Manager
> > > W.K. Kellogg Biological Station
> > > Michigan State University
> > > Hickory Corners, MI   49060
> > > 269/671-2337
> > > tbergsma at kbs.msu.edu
> > > http://lter.kbs.msu.edu
> > > _______________________________________________
> > > eml-dev mailing list
> > > eml-dev at ecoinformatics.org
> > > http://www.ecoinformatics.org/mailman/listinfo/eml-dev
> >
> > --
> > \SEC
> > _______________________________________________
> > eml-dev mailing list
> > eml-dev at ecoinformatics.org
> > http://www.ecoinformatics.org/mailman/listinfo/eml-dev
> 
> --
> Tim Bergsma
> LTER Information Manager
> W.K. Kellogg Biological Station
> Michigan State University
> Hickory Corners, MI   49060
> 269/671-2337
> tbergsma at kbs.msu.edu
> http://lter.kbs.msu.edu

-- 
Tim Bergsma
LTER Information Manager
W.K. Kellogg Biological Station
Michigan State University
Hickory Corners, MI   49060
269/671-2337
tbergsma at kbs.msu.edu
http://lter.kbs.msu.edu