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. ---