This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
Changing rrdb objects in the future
- Previous message (by thread): Changing rrdb objects in the future
- Next message (by thread): Changing rrdb objects in the future
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Wilfried Woeber, UniVie/ACOnet
woeber at cc.univie.ac.at
Mon Apr 14 10:54:19 CEST 1997
=At 02:46 PM 4/08/97 -0400, you wrote: =>At the last ripe meeting it was agreed to track object history =>including UTC time zone, although I'm not entirely clear what this =>means. Presumebly it means that the changed field will be stamped =>automatically by the db software with utc time and the from =>line of the email. = =That would certainly sort it out. The RIPE-DB WG proposed to have the db update mechanism *automatically* tag objects being updated with a UTC timestamp (and some other data). This data would *not* be under the control of the submitting entity. It is not meant to replace or modify any data in the changed: field as supplied by the submitting entity. This change is already on the RIPE-NCC's to-do-list for implementation. => I think another holdup is the issue of the millenium approaching. =>The current date format (ie, YYMMDD) will be insufficient for those =>future dates. And so this problem must be fixed too. => I would think that YYYYMMDD is an obvious solution. The RIPE DB production software already accepts objects with the extended 8 character format. =That will take care of the y2k problem, but won't help those of us in =unusual time zones... For that we would need something like YYYYMMDDHHMMZZZ =(ZZZ=time zone). This is a bit more of a mouthful, of course. I think local time details (time zones, DST, whatever) should become a non-issue as soon as we get the changed: data decoupled from the UTC time stamps as applied by the db update process? =>The db software =>will be converted from ripe181 to rpsl over the coming 6 months. =>Maybe when the db's are officially changed to rpsl we can update =>the objects from YYMMDD --> YYYYMMDD format. => =>ps Yes, this is exactly the correct forum to bring this up. = =Good :) Although I wonder whether it would be useful and more consistent to convert all the exiting objects from the 6 character to the 8 character format and to expand the 6 character format on the fly during the update processing... Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------
- Previous message (by thread): Changing rrdb objects in the future
- Next message (by thread): Changing rrdb objects in the future
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]