Re: [sqlite] ISO time leap second.

2014-07-29 Thread Nico Williams
On Tue, Jul 29, 2014 at 10:02 AM, Simon Slavin 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

Re: [sqlite] ISO time leap second.

2014-07-29 Thread Simon Slavin
On 29 Jul 2014, at 5:36am, Nico Williams wrote: > Note that SQLite3 apparently does no > corrections for leap seconds anyways in date arithmetic (which it > can't do if you're using numeric arithmetic on Julian days anyways!), > which it would have to do (since UTC is

Re: [sqlite] ISO time leap second.

2014-07-28 Thread Nico Williams
On Mon, Jul 28, 2014 at 7:54 PM, James K. Lowden wrote: > On Mon, 28 Jul 2014 16:32:42 -0500 > Nico Williams wrote: >> Raising errors is not that useful here: most users who ever run into >> such timestamps will not really know what to do with

Re: [sqlite] ISO time leap second.

2014-07-28 Thread James K. Lowden
On Mon, 28 Jul 2014 16:32:42 -0500 Nico Williams wrote: > The word "solar" does not appear on > http://sqlite.org/lang_datefunc.html . Instead it's explicitly stated > that "Universal Coordinated Time (UTC) is used". Quite. > Still, ISTM that "UTC is used" implies

Re: [sqlite] ISO time leap second.

2014-07-28 Thread jose isaias cabrera
"Igor Tandetnik" wrote... On 7/28/2014 12:37 PM, jose isaias cabrera wrote: I claim that I am not an expert, but is this one a valid ISO time stamp? If so, then that ISO must be revised, as that time does not really exists ever. That time does really exist, occasionally:

Re: [sqlite] ISO time leap second.

2014-07-28 Thread Nico Williams
On Mon, Jul 28, 2014 at 12:20 PM, Keith Medcalf wrote: > It may or may not be a valid timestamp depending on what your time > representation is. SQLite does not use UTC (which is an artificial timescale > maintained by a bunch of atomic clocks). SQLite (and most other

Re: [sqlite] ISO time leap second.

2014-07-28 Thread Keith Medcalf
>Sent: Monday, 28 July, 2014 10:38 >To: General Discussion of SQLite Database >Subject: Re: [sqlite] ISO time leap second. > > >"Igor Tandetnik" wote... > >> On 7/28/2014 11:49 AM, Jan Nijtmans wrote: >>> 2014-07-28 17:10 GMT+02:00 Igor Tandetnik <i.

Re: [sqlite] ISO time leap second.

2014-07-28 Thread Jan Nijtmans
2014-07-28 18:28 GMT+02:00 Igor Tandetnik : > What do you mean "ignore"? Can you specify precisely what the semantics of > such a timestamp should be, in all the date/time manipulation operations > SQLite supports? Just as julianday('2012-06-30T24:00:00') is exactly equal to

Re: [sqlite] ISO time leap second.

2014-07-28 Thread Igor Tandetnik
On 7/28/2014 12:37 PM, jose isaias cabrera wrote: I claim that I am not an expert, but is this one a valid ISO time stamp? If so, then that ISO must be revised, as that time does not really exists ever. That time does really exist, occasionally: http://en.wikipedia.org/wiki/Leap_second --

Re: [sqlite] ISO time leap second.

2014-07-28 Thread jose isaias cabrera
"Igor Tandetnik" wote... On 7/28/2014 11:49 AM, Jan Nijtmans wrote: 2014-07-28 17:10 GMT+02:00 Igor Tandetnik : All your fix does is have the parser accept "60" as valid seconds field. That's not very interesting. julianday('2012-06-30T23:59:60'), and how should it

Re: [sqlite] ISO time leap second.

2014-07-28 Thread Igor Tandetnik
On 7/28/2014 11:49 AM, Jan Nijtmans wrote: 2014-07-28 17:10 GMT+02:00 Igor Tandetnik : All your fix does is have the parser accept "60" as valid seconds field. That's not very interesting. Yes, that's exactly all that I'm after. ISO 8601 does not specify how leap seconds

Re: [sqlite] ISO time leap second.

2014-07-28 Thread Jan Nijtmans
2014-07-28 17:10 GMT+02:00 Igor Tandetnik : > All your fix does is have the parser accept "60" as valid seconds field. > That's not very interesting. Yes, that's exactly all that I'm after. ISO 8601 does not specify how leap seconds are handled, it just specified which

Re: [sqlite] ISO time leap second.

2014-07-28 Thread Igor Tandetnik
On 7/28/2014 10:58 AM, Jan Nijtmans wrote: 2014-07-28 16:53 GMT+02:00 Richard Hipp : Better to keep the code simpler and just say that SQLite (and hence Fossil) does not know about leap seconds. If you can do that in two bytes ;-) All your fix does is have the

Re: [sqlite] ISO time leap second.

2014-07-28 Thread Jan Nijtmans
2014-07-28 16:53 GMT+02:00 Richard Hipp : > Better to keep the code simpler and just say that SQLite (and hence Fossil) > does not know about leap seconds. If you can do that in two bytes ;-) Regards, Jan Nijtmans ___

Re: [sqlite] ISO time leap second.

2014-07-28 Thread Richard Hipp
Better to keep the code simpler and just say that SQLite (and hence Fossil) does not know about leap seconds. On Mon, Jul 28, 2014 at 10:49 AM, Jan Nijtmans wrote: > According to , the > following should be perfectly valid: > >

[sqlite] ISO time leap second.

2014-07-28 Thread Jan Nijtmans
According to , the following should be perfectly valid: $ fossil new --date-override 2012-06-30T23:59:60 foo.fossil unrecognized date format (2012-06-30T23:59:60): use "-MM-DD HH:MM:SS.SSS" Suggested patch to fossil (and SQLite trunk, with adapted