Julian Date format -- interval not dateTime (my thought)
Tim Bergsma
tbergsma at kbs.msu.edu
Mon Mar 24 06:51:15 PST 2003
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
More information about the Eml-dev
mailing list