[Babase] Using Datetime columns after all

Catherine Markham (amarkham at Princeton.EDU) amarkham at Princeton.EDU
Sun Nov 20 15:08:19 EST 2005


Hi Karl,

Sorry but I'm just not following - how (or why) would we have done something to the date/time column for the interacts table?  Again, if you're referring to something you and I talked about not that long ago, I was simply asking about how to design the spreadsheet for the weather data... I think it was different than what you're talking about now.  

As for keeping the date/time column from Psion included in the new tables, I'm definitely for that.  I was trying to point out that the times in that column might not be what you'd logically expect from Psion protocols (in other words, 60 sec intervals).

Catherine

----- Original Message -----
From: "Karl O. Pinc" <kop at meme.com>
Date: Sunday, November 20, 2005 2:55 pm
Subject: Re: [Babase] Using Datetime columns after all
To: The Baboon Database Project <babase at eeblistserv.Princeton.EDU>

> In summary: the design is more or less as now, or actually
> as before the foxpro Datetime columns were added (they were
> always something of a workaround), but I'll be
> getting the times from the Datetime columns,
> in some cases, for the conversion
> as this is more accurate and allows us to keep
> the original data at-hand.
> 
> I'll have the interations et-al documented soon, although you're
> welcome to look at what's up already.  But, I wanted to make sure
> I can still get the times from Datetime -- that nothing had
> happened to the data in there.
> 
> On 11/20/2005 08:14:41 AM, Catherine Markham 
> (amarkham at Princeton.EDU)  
> wrote:
> > Hi all,
> > 
> > I remember asking Karl about date/time columns in general when I 
> first> started working with the weather data.  We already had a 
> date column,
> > but we wanted to add the time as well - I was asking whether this
> > could be a separate column or had to be together in one date/time
> > field.  I'm still not entirely sure from Karl's email what the 
> answer> is, but my preference would be the data separated in 2 
> columns (which
> > is the way I have it now).
> 
> The answer depends on where in the database we're talking about but
> IIRC in the interaction related stuff the dates and times are
> separated.
> 
> > As for the date/time info from Psion, I always had the 
> impression that
> > Psion data were analyzed by considering that each consecutive sample
> > is 1 minute from the last sample - regardless of the details of the
> > date/time stamp associated with each reading.  Of course that's
> > definitely something to check with Susan, but the I thought the
> > date/time just reflected when the team got the data entered in Psion
> > and was not necessarily associated with the exact time of the
> > observation.  I think if you look closely at the time intervals
> > between samples, you'll see they certainly aren't always 60 seconds
> > apart (as I think the protocol says they should be).
> 
> I believe you're right, but I also see no reason for throwing away the
> seconds.  It's easy enough to make the database pretend they don't
> exist, one way or another.  In some ways they definately come in handy
> now and, while I could pre-process this out and discard the extra 
> data,I'm always of the mind to keep the original data in case you ever
> want to re-process it.  Regardless this is a discussion we need to
> have and it's probably better to have it once we've documentation
> to work from.
> 
> > 
> > But (here comes my disclaimer...) that's just based on my impression
> > after glancing through the Psion related tables - I've never really
> > looked at it in more detail beyond that.
> 
> We'll definatly talk about it.  In the meantime, has Datetime been
> munged anywhere lately?
> 
> 
> Karl <kop at meme.com>
> Free Software:  "You don't pay back, you pay forward."
>                  -- Robert A. Heinlein
> 
> _______________________________________________
> Babase mailing list
> Babase at www.eco.princeton.edu
> http://www.eco.princeton.edu/mailman/listinfo/babase
> 


More information about the Babase mailing list