Problem statement :  Perils of date and timestamp management

                     viz. translating into who,whom,why,How.

                     From a operating system context why should a
                     system admin be provided to manipulate date,timestamp

                     i.e. systemclock ...perils of changing or varying the date
                     or timestamp or running system
 
Opportunity a:        

                     Translating into delegation of such authority or previleges ??

                     ....ideally any interface to manipulate CMOS clock

                         or update the processor counters ...cloak cycle counting

                         ....should ideally be disabled

                     similarly ...synchronization of the clock of cloak counters
                     ....over network ..either NTP ....translating into confulence
                     of power at one-point ....resulting into pontentially large
                     scale manipulations ....


                     hence ideally ....a difference of systemclock with those of
                     NTP ...should be ...ideally brought to notice of all the users
                     of the system ...kind of wall broadcast when a system is going
                     down as also the  unix syslog ...management.



Opportunity b: while NTP is usuallly configuration based setting synchronization from a
               server.

               At times ....apply use-case modelling to derive use-case's ....there 
               
               may be requirement to programmatically manipulate or set the time on a
               client host.

               Thus deriving a standard or protocol for manipulating and altering or setting
               the clock of a host , post using either a PGP or PKI kind of validation or
               authentication for validty, authenticity of such transactions (for instance
               may refer to validation of certain database instance's using host-id combination
               as an example illustration for the above use-case).


Opportunity c: Deriving from a) and b) as above ....applying use-cases ...


               many a countries support multiple time-zone's ....hence requiring the ability to support
               multiple time-zones or timestamps on server's at instances.

               Thus a hash-map that carries the primary time-zone and zonal' time difference from which the
               respective regional timestamps can be computed.

               The above hold's significance particularly with transactions that require or that needs to
                be accompanied with a timesstamp.


Opportunity d: problem statement ...ability to do a bool validation on a timestamp ,

               ...many a time input-validation of date, time in 2/3 tier architecture's,

               ability validate a date/time as a valid input using a regular-expression i.e. validity of the date-value,

               given that most user-interfaced input (captured using client-side timestamp) needs to be
               translated into a valid date/time format

               use-case-scenario: dynamic navigation of elements in a HTML-form / XML-attributed ...ability to validate
                                  the user-input against it's data-type and input-criteria.           

              
              
Note: The above problem statement having been encountered in various scenarios
      and detailed in various 'Proof of concepts' as mentioned in 
      
       http://uk.geocities.com/ravivenkatus/projects.pdf
       http://ravishankarkv.tripod.com/projects.pdf
        ....apply appropriate
      'use-case' modeling, rationalize and arrive at a workable and feasible 
       solution both commercially and techinically viable.

             

           


 
             