Doug, At 19:47 15/09/2009, you wrote: ´¯¯¯ >I'm not sure if you are looking to make a entry unique, or determine >the order in which the entries occurred. In either case, be aware - >time can go *backwards* on a system, especially if it is being syncd >to an outside source such as with NTP. > >Normally the 'jitter' is under a second, but exceptions do occur >(including the one where the Sysadmin changes the system clock!). Note >that a backward "jitter" could (conceivably) result in the same >timestamp occurring twice. Also, depending on the resolution of the >clock (which may vary depending on installation options) it may be >possible for two entries to occur at the same 'time'. As a result, >I've sworn off using the time for anything more than a logging label. `---
That's very true. Time also sometimes get "weird", i.e. UTC time at leap seconds. Depending on the time source, system settings and possibly some untold libraries, not all installations cope gracefully with timestamp = 2008/12/31 23:59:60 xxx. Some systems, when their are informed well ahead of the next occurence of a leap second, shift time gradually over weeks so as to avoid a 60th second. I confess this is a relatively rare event, but it does occur. For applications dealing with massive 24/7 input, the chance of recording rows during such leap second is 100%. It seems to be no problem when recording an epoch-type timestamp, but when this is displayed or selected, such leap second is likely to shift the timestamp to the next month or year, which can make a huge difference in particular situations. There are discussions about getting rid of or maintaining leap seconds within UTC. Nonetheless and independently of future decisions those that have already occured... well, they have occured! Google for leap seconds. In particular Wikipedia give the schedule and also mentions: Several arguments for the abolition have been presented. Some of these have only become relevant with the recent proliferation of computers using UTC as their internal time representation. For example, currently it is not possible to correctly compute the elapsed interval between two instants of UTC without consulting manually updated and maintained tables of when leap seconds have occurred. Moreover, it is not possible even in theory to compute such time intervals for instants more than about six months in the future. This is not a matter of computer programmers being "lazy"; rather, the uncertainty of leap seconds introduces to those applications needing accurate notions of elapsed time intervals either fundamentally new (and often untenable) operational burdens for computer systems (the need to do online lookups) or insurmountable theoretical concerns (the inability in a UTC-based computer to accurately schedule any event more than six months in the future to within a few seconds). Posted outside any leap second to avoid any embarassment. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
