webservice dive matching?

[Aurélien PRALONG]

You misunderstand the problem. The companion never created doubles. It's
when synchronising with the server that doubles appear, because the
companion doesn't save date sent as string, but an utc timestamp, and use
them to match server / local dives.  So if you send data, and change
timezone, when synchronising again, a different utc timestamp will be
generated => double.

So I will store the local time as a string. This should fix the bug. I'm
sorry I didn't realise gmt is not suitable.

Aurelien
Le 21 mai 2013 18:35, "Linus Torvalds" <torvalds at linux-foundation.org> a
écrit :

> On Tue, May 21, 2013 at 9:06 AM, Aurélien PRALONG
> <aurelien.pralong at gmail.com> wrote:
> >
> > We already had a discution about how we should handle timezones in the
> > mailing list. The problem was that the companion needs a absolute time
> (so
> > timezones) to keep a coherent list.
>
> Why?
>
> This all makes no sense. The companion app should never use anything
> but local-time, and that's what I remember from the discussion last
> time too. You were the only one who thought it needed something else.
>
> If you need an ID. use an ID. But make sure that that ID is never
> mistaken for a date (for example, it could be a *hash* of a timestamp
> or something - just to make sure that you can't use it even by mistake
> as a date).
>
> But better yet, just use the localtime. Collisions don't really
> happen. Even if you were to drive between timezones and do two dives
> in quick succession, why would they be exactly the same number of
> hours apart? They wouldn't.
>
> The only time that could be confusing might be if the app is set for
> "do automatic samples every fifteen minutes", and because an hour is
> exactly divisible by 15 minutes, and you keep moving and change the
> timezone while it's on, you might have the same date repeated exactly.
> But how about just setting the timer for one second longer?
>
> That said, it looks like the current companion app doesn't even send
> in seconds. *That* is a much better way to avoid duplicates than using
> GMT.
>
>                Linus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130521/33c03037/attachment.html>