tomdroid-dev team mailing list archive

[Sandy Armstrong <sanfordarmstrong@xxxxxxxxx>]

On Fri, Jan 22, 2010 at 9:59 PM, Olivier Bilodeau
<olivier@xxxxxxxxxxxxxxxxx> wrote:
> Hi guys,
>
> Just a quick one for you.
>
> last-change-date's time format seems rare outside of Mono / .Net. I am
> obliged to use an extensive DateTime library in java to lazily understand
> the format and now I just realized that sqlite's datetime methods doesn't
> deal with all the format cleanly.
>
> <last-change-date>2008-10-21T22:17:05.8281250-04:00</last-change-date>

We had a similar issue with our chosen format when people were moving
notes back and forth between Tomboy and Gnote:

https://bugzilla.gnome.org/show_bug.cgi?id=581844

> The problematic portion on the sqlite front is the timezone portion after
> the minus. It's not there. On the Java side, it seems like a precision
> problem, missing millisecond precision.
>
> The thing is: how much should I care? Is it a problem if snowy / tomboy
> thinks last-change-date is:
> 2008-10-21T22:17:05.8281250-04:00
>
> and through sqlite I have:
> 2008-10-21T22:17:05.828
>
> although in string I have:
> 2008-10-21T22:17:05.828-04:00

Well, I'm not entirely sure I understand the last part, there, but
obviously the time zone information is important because without it
you can't know the absolute time.  And the time zone could be
different on every note, so you need to be able to properly parse the
datetime string so that you are storing your datetimes consistently.

If there is a better "universal" datetime format (for example, just
using Zulu), then let's figure that out and we can update the REST API
spec to be a little more specific about what datetime formats it
accepts and what format it returns.  Fixing Snowy would be easy here;
I can't speak for the U1 guys, I guess it depends on how they store
the dates.

Sandy