Re: Immediate - Date in Changed field

[Carol Orange <]

In message <9701131817.AA09140@localhost>, 
Joachim Schmitz writes:

>> 
>>  Dear Cengiz,
>> 
>>  you wrote:
>> > Date: Mon, 13 Jan 1997 10:14:20 -0800
>> > Message-Id: <199701131814.AA22919@localhost>
>> > From: Cengiz Alaettinoglu cengiz@localhost
>> > To: noc@localhost
>> > Cc: woeber@localhost (Wilfried Woeber, UniVie/ACOnet),
>> >         Carol.Orange@localhost, db-wg@localhost
>> > Subject: Re: Immediate - Date in Changed field
>> > 
>>  [...]
>> > > >   Hi DB-folks!
>> > > > 
>> > > >   On a slightly different aspect,
>> > > >   and assuming that we change things anyway...
>> > > >   
>> > > >   How about running the RIPE-DB (and maybe gradually all the others :-
>> ) on
>> > > >   a UTC basis, according to some recent suggestions? 
>> > > 
>> > >  I think both the 4 digit year presentation and the UTC basis (I estimat
>> e
>> > >  this includes hh:mm:ss as well) are a very valuable extension for time
>> > >  stamps in the RIPE-db. This might as well ease some of the troubles in
>> > >  updates within the "near real time" mirrors.
>> > 
>> > I definitely agree for the need for this. But the changed attribute is
>> > inserted by the person who registers the object, not by the database
>> > software, he has the full control over which timezone he uses and to
>> > lie.
>> > 
>> > May be what we really want is a timestamp field with the granularity
>> > you suggest and in UTC zone, but inserted to the objects automatically
>> > by the database software. I see a lot of value in this.
>> > 
>>  I completely agree with you. This can only be done if the database software
>>  sets the time stamp. I guess this also solves most of the race conditions
>>  otherwise implied.

This would most definitely be a significant improvement (but is a 
different point than the "changed" field) I believe this is on the
the list of Open Issues to be reviewed next week. If not it will be
then.

Greetings,

-- Carol