Gerald Winters suggests (see below) that this work group might be a good place to discuss the timezone used when calculating a proper date for the changed: field of RADB objects. Is there a valid rationale for the RADB's use of a local timezone rather than Universal Time? If not, can this work group make a recommendation (formally or otherwise) to the RADB suggesting Universal Time be used to calculate the date for this field? The other inter-registry consistency issues Gerald mentions are likely important too, but this one seems ... totally without controversy. Or am I missing something? -- Sean Shapira sds@jazzie.com +1 206 443 2028 Gerald A. Winters (gerald@merit.edu)
Sean,
Actually there are some good reasons to use universal time. For example, we import the ripe registry and they are not using EST as we are. So there is some conflict there. There has been talk of enforcing consistency among the registries (ie, aut-num policy, maintainer registration, ...) and the changed date (ie, time-stamping) will undoubably play an important role. I think the changed data is ignored to a certain extent because humans supply the date and not the software. The software only checks for dates in the future, I believe, but will accept dates in the past. So the changed date is more like a hazy indicator rather than a precise time stamp. You know the the real/exact changed date is <= to the actual changed date. The place to bring this point up is at the RIPE meetings to the data base working group.
--Gerald
Sean Shapira writes:
In response to a recent RADB update request I received:
WARNING: date in "changed" (961113) is in the future - changed to 961112
The trouble? I'm guessing auto-dbm@ra.net was using Eastern Standard Time; I was using Universal Time. It seems a window of vulnerability exists during which auto-dbm has an incorrect idea of the "one true date" ;-).
Seriously, as the global route registration database of last resort, doesn't using Universal Time in the RADB make sense?
-- Sean Shapira sds@jazzie.com +1 206 443 2028 Serving the Net since 1990.
-- Gerald A. Winters gerald@merit.edu Merit Network, Inc. (313) 747-3522 (office) 4251 Plymouth Road, Suite C. (313) 747-3745 (fax) Ann Arbor, MI 48105-2785
Hi Sean,
Sean Shapira writes :
Gerald Winters suggests (see below) that this work group might be a good place to discuss the timezone used when calculating a proper date for the changed: field of RADB objects.
This is indeed the right group.
Is there a valid rationale for the RADB's use of a local timezone rather than Universal Time? If not, can this work group make a recommendation (formally or otherwise) to the RADB suggesting Universal Time be used to calculate the date for this field?
As Gerald Winters said: The changed field is supplied by the human user. It only contains a date field without the time. The changed field is therefore not really usefull for consistency checks and the like even if you use UTC. However, it can be very usefull to show a history of change by the owner of the object to the public. The changed field will thus only tell you something about the object in which it is used. Using universal time will not make things more clear since the owner of the object usually lives in just one time zone (of course the are some exceptions ;-)). However, this doesn't mean that I am very satisfied with this behavior ...
The other inter-registry consistency issues Gerald mentions are likely important too, but this one seems ... totally without controversy. Or am I missing something?
There is already a proposal for solving the consistency issues (regarding the time and order of updates). This involves the automatic adding of a serial number attribute that includes a UTC time stamp & and ever increasing number which wraps to 0 at 31-bit boundaries. Time & priority constraints never allowed to actually implement it. Note that an internal invisible serial numbering scheme already exists which is used for the near-real time mirroring of the databases. Adding the serial number attribute would make this mirroring service much more robust and reliable although it also works surprisingly well (although not perfect) without it... David K. ---
participants (2)
-
davidk＠isi.edu -
sds＠jazzie.com