If the datr/time is stored internally as utc iso8601 text then it will remain compatible with old versions and can implement whatever new behavior is needed on new versions. The bigger question is 'what new behavior'? The only nee behavior seems to be 'let this third party package see it as a date', which it should be able to figure out by looking at the schema. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
- Re: [sqlite] Backward compatibility vs. new featur... Simon Slavin
- Re: [sqlite] Backward compatibility vs. new fe... Thomas Kurz
- Re: [sqlite] Backward compatibility vs. ne... Simon Slavin
- Re: [sqlite] Backward compatibility vs. ne... Thomas Kurz
- Re: [sqlite] Backward compatibility vs. ne... Simon Slavin
- Re: [sqlite] Backward compatibility vs. ne... Thomas Kurz
- Re: [sqlite] Backward compatibility vs. ne... Keith Medcalf
- Re: [sqlite] Backward compatibility vs. ne... Ling, Andy
- Re: [sqlite] Backward compatibility vs. ne... Dominique Devienne
- Re: [sqlite] Backward compatibility vs. ne... Ling, Andy
- Re: [sqlite] Backward compatibility vs. ne... Peter da Silva
- Re: [sqlite] Backward compatibility vs. ne... Thomas Kurz
- Re: [sqlite] Backward compatibility vs. new features (w... Keith Medcalf
- Re: [sqlite] Backward compatibility vs. new featur... D Burgess
- Re: [sqlite] Backward compatibility vs. new featur... Tim Streater
- Re: [sqlite] Backward compatibility vs. new featur... Thomas Kurz
- Re: [sqlite] Backward compatibility vs. new fe... Tim Streater
- Re: [sqlite] Backward compatibility vs. ne... Simon Slavin
- Re: [sqlite] Backward compatibility vs. ne... J Decker
- Re: [sqlite] Backward compatibility vs. ne... Tim Streater
- Re: [sqlite] Backward compatibility vs. ne... J Decker