On Tue, Jul 29, 2014 at 10:02 AM, Simon Slavin <slav...@bigfraud.org> wrote: > You're never going to get non-scientific programmers to do this properly > anyway. Every financial programmer knows that there are exactly 60*60*24 = > 86,400 seconds in a day. You've never going to get them to use library > routines to work out how many seconds there are in a 30 day period.
I'm not sure that this doesn't matter to people dealing with financial data, but I suspect that if someone cares about TAI in financial data then they probably care about having very high resolution timestamps too (think of high speed trading). Perhaps the same goes for astronomers, actually: millisecond resolution probably isn't enough if you really care about one second. (Of course, the accumulated error from ignoring leap seconds across decades-long intervals will be larger than one second, but still, I think it's fair to infer that astronomers probably care about higher time resolutions than a millisecond. I think that's getting close to beating this poor horse a bit too much. Count me as in favor ignoring second values of 60 when parsing seconds. Dealing with TAI reliably would require extending the existing date functions, or adding new ones, to at minimum do TAI<->UTC (and/or Julan day) conversions. Given that it should be possible to produce functions that do date arithmetic by converting inputs to TAI as necessary (assuming it's possible to tell UTC inputs from TAI inputs). FYI: http://cr.yp.to/proto/utctai.html DJB also has a library for converting between TAI and UTC that might be useful here: http://cr.yp.to/libtai.html . Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
