Re: [RADB #2390] RADB Timezone

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