Re: Immediate - Date in Changed field
-
To: noc@localhost
-
From: Cengiz Alaettinoglu cengiz@localhost
-
Date: Mon, 13 Jan 1997 10:14:20 -0800
-
Cc: woeber@localhost (Wilfried Woeber, UniVie/ACOnet), Carol.Orange@localhost, db-wg@localhost
-
Posted-date: Mon, 13 Jan 1997 10:14:20 -0800
Joachim Schmitz (Schmitz@localhost) on January 13:
>
> Dear Wilfried, dear Carol,
>
> regarding time stamps in the RIPE-db you wrote::
> > Date: Mon, 13 Jan 1997 13:58:20 MET
> > From: "Wilfried Woeber, UniVie/ACOnet" woeber@localhost
> > To: Carol.Orange@localhost
> >, woeber@localhost
> > Message-Id: <009AE4E2.4C214CCA.9@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 estimate
> 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.
>
> Joachim
>
> > Just for a sneak preview on one of the small agenda items for the DB WG :-)
> >
> > Wilfried.
> >
> > ~~~~~~~~~~
> >
> > Dear Database WG members,
> >
> > We have been requested to ease the restrictions on the date
> > in the "changed" attribute to allow for dates with 4 digit years
> > specifically those starting with "19" and eventually "20".
> >
> > For obvious reasons, we agree with this proposition. However, we
> > also understand that some of you may have software which presumes
> > the date has the yymmdd format.
> >
> > If anyone has a serious problem with this change, please notify me
> > personally (orange@localhost) before the end of the week.
> >
> > If we don't hear any show stoppers before the end of the week, we
> > will proceed. Thereafter, the following will be acceptable formats:
> >
> > 19yymmdd
> > 20yymmdd (eventually)
> > yymmdd
> >
> > Thanks for your ear,
> >
> > -- Carol Orange
> >
> > --------------------------------------------------------------------------------
> >
Cengiz
--
Cengiz Alaettinoglu Information Sciences Institute
(310) 822-1511 University of Southern California
http://www.isi.edu/~cengiz
|