lordi / tickmate

One bit journal
GNU General Public License v3.0
111 stars 34 forks source link

Date decomposed in DB vs Datetime Object Storage #156

Closed NicolasFlandrois closed 2 years ago

NicolasFlandrois commented 2 years ago

Hi!

My question is not a bug report, and probably will not have any impact (might even be useless). But I am trying to understand something.

From your code, you are calling a date/time object, then decompose it in order to store it in database. My question is: Why?

Or rather why not store a Date/Time Object directly (timestamp or epoch)? One benefice of using timestamps could remove the column has_time_info. Multiple ticks/clicks will have a new insert/entry at least a few ms apart. Each tick in each track is recorded (or seem to be) individually each time we click/tick anyway. But there is certainly something I didn't see or some constraints that influenced your choice.

Trying to understand the constraints, choices, and implications behind it. And sharing some thoughts. Thank you if any replies. That would help me improve!

lordi commented 2 years ago

Hi Nicolas,

first off, that code is probably 8+ years old so my memory might be a little hazy.

In the first version we did not have multiple ticks at all. It was truely 1-bit for each day. I think the reason why I choose to store the concrete day and not the datetime object or timestamp is that you would not have any problems with different timezones you might travel through. A tick should be registered for a specific day, not for a timestamp. Later we added the multi-tick feature.

Probably many things could be improved when one would re-write this app today :-)

Cheers, Hannes

NicolasFlandrois commented 2 years ago

Thanks a million!