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/[email protected]/
[RADB #2390] RADB Timezone
- Previous message (by thread): [RADB #2390] RADB Timezone
- Next message (by thread): No subject
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
davidk at isi.edu
davidk at isi.edu
Wed Nov 13 22:41:24 CET 1996
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. ---
- Previous message (by thread): [RADB #2390] RADB Timezone
- Next message (by thread): No subject
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]