Dates keep reseting and changing

[fitjova]

I'm having an issue on my device running android 8.1 where the default day in the diary is never the day it currently is. It will often reset to the day before or the day before that.

I can manually select today's date, but after I add the food or go back to the diary later in the day to add more it defaults to a different day(sometimes with todays food added into yesterday's date).

As a side note I'm super excited to see an open source calorie tracker out here. This app is simple, clean, and doesn't nag me to subscribe to their annual service while Im trying to input foods.

[davidhealey]

This is a strange bug. What phone are you using? And which version of Android (I know you said 8.1 but is it a custom rom?) Also what version of Waistline?

[jingofett]

Having this same issue on a LG G3 LineageOS 14.1. Using version 2.2.3 of the app

[davidhealey]

I'm on LineageOS 14.1 too but I haven't come across this bug yet. Does it happen every time you use the app or is it random? Is it something that you could catch on video?

[fitjova]

I'm on lineage os 15.1. Here is a video https://gfycat.com/NaturalThriftyBordercollie

[davidhealey]

Thank you, very helpful. Did this happen in any previous versions?

[Lense]

The same thing is happening for me consistently. Don't know if it happened in previous versions since I just installed the app. I can try an older version if it would help.

Version 2.2.3 of app from google play store. Nexus 6P running Lineage 15.1-2018-0903-NIGHTLY-angler.

[davidhealey]

Yes, please try an older version and let me know, that will be very helpful in finding the cause of this issue.

[Lense]

Still happens in 2.1.0

If there's a specific older version you want me to try, lmk.

[davidhealey]

Could you try 2.0.0 as well, that was the earliest version with the current system. It is starting to sound like this is a problem that's been there since v2, in which case I'm not able to reproduce it on my device. I'll have to get hold of some other devices so I can duplicate the problem but in the meantime I can try some things and you guys can test it.

[Lense]

Still happens in debug 2.0.0 build.

[davidhealey]

Thanks for confirming, that means it's been there for a while which implies the problem isn't widespread. So I shall start poking around the date handling when I'm putting together the next update and see if I can find something that looks like it could be causing this issue.

[Mitlik]

I can confirm this bug on Android 8.0.0 (Sprint Samsung Galaxy S7) through the past 3 versions released on f-droid (currently 2.2.3).

[davidhealey]

Hi guys, I've had a thought about this. I'm in the UK and my phone uses the date format dd/mm/yyyy, I notice in the GIF that was posted the date was in mm/dd/yyyy format.

Are all of you using this date format, with the month first?

[Mitlik]

Yes, using US default format (mm/dd/yyyy) here.

[davidhealey]

I just tested changing the date format on my phone to US but I still can't reproduce the issue :( could you try changing to UK and seeing if the issue is resolved?

Also I think I just found another related bug. If you change the date with the little arrows rather than with the date picker do you get different results? For me changing with the date picker caused the food to be added to the current date, even if I selected a different date.

[Mitlik]

I switched to English UK language and restarted to get the date format to change, but the issue persists. Still loads to yesterday by default and returns to previous dates after adding an entry to the diary.

[davidhealey]

Darn, oh well it was worth a try. I'll keep thinking and eventually it will get fixed

[Mitlik]

I just noticed your comment about the date arrows. I haven't used them because "next date" doesn't work.

When I use "previous date" and then add a food the date still changes. If I navigate back and forth enough eventually the added item appears in the diary on the date I added it for. I don't see it populating anything in today's date.

(Edit: addt'l detail)

[davidhealey]

Oh that's strange. Javascript dates are a pain in the butt in general so it's not too surprising that this part of the app has some bugs, just wish they were easier to nail down. I'll get there.

[davidhealey]

Ok I've made some changes to the date system, there is a debug build available here - https://github.com/davidhealey/waistline/tree/v2.3/platforms/android/app/build/outputs/apk/debug

Be warned however that installing this build may overwrite your existing install and delete your current data.

[Mitlik]

I'm having issues installing apks not from an app store (it happened when I tried installing another apk as well so I'm pretty sure it's my issue). So while I would love to help test this build, I am running into difficulties.

If anyone is willing to trouble shoot this with me:

• running the stock samsung image for galaxy s7
• enabled firefox and my files to install unknown apps
• after opening the apk it displays a a progress bar then ends by saying app not installed

If there are already enough testers I can wait until the new version hits f-droid.

[Lense]

@davidhealey That debug apk seems to have some new bugs (like going back to statistics page whiile trying to add food to diary) that git master doesn't have, so I'm just going to focus on master.

git master has some improvements and some new bugs:

bugs

• Diary opens to the day before the current date
• When I select a date through the picker, it actually goes to 2 days before then

fixed

• The back/forward arrows seem to work
• Adding foods goes back to the date that was open before.

@Mitlik That can happen when the previous version is not completely uninstalled. You can try installing through adb install to see more debug output. For me, adb uninstall com.waist.line fixed it.

[Mitlik]

I've confirmed the behavior reported by lense, and i see the same improvements and issues. Including returning to home page after adding item to food list while trying to make a diary entry. The food list doesn't seem to save in the debug apk either. But those might be fixed in master.

Thanks @lense for the install tip.

[davidhealey]

Thanks guys. Are these issues in the latest release - https://github.com/davidhealey/waistline/releases/tag/2.3.0 ?

[Mitlik]

Installed the new linked rev:

• Diary still opens to yesterday.
• Date selector still opens two days prior to the selection

Will have to test out other noted issues later.

[davidhealey]

Darn,I'm sure this is something to do with location but when I set my phone to US I still can't reproduce the issue. I'll have to try something else.

[davidhealey]

@davidhealey That debug apk seems to have some new bugs (like going back to statistics page whiile trying to add food to diary) that git master doesn't have, so I'm just going to focus on master.

git master has some improvements and some new bugs:

bugs

* Diary opens to the day before the current date

* When I select a date through the picker, it actually goes to 2 days before then

Ok I changed all of my phone settings to US and restarted my phone and now I can recreate these two bugs. So the next step is to fix it. Hopefully it won't take long and I'll have a new release today.

[Mitlik]

Brain wave: the diary opening to yesterday issue might be linked to the statistics page not loading information for the current day.

I tried switching back to English UK for language and the locale still didn't seem to make a difference.

[davidhealey]

Brain wave: the diary opening to yesterday issue might be linked to the statistics page not loading information for the current day.

I tried switching back to English UK for language and the locale still didn't seem to make a difference.

I didn't know there was an issue with the statistics page. Please make a new github issue for it and I'll fix it.

[davidhealey]

Hi Guys, I've been working on this all day, Javascript dates are horrible! Anyway I think I have something that might work. I've created a new branch for this and there is a debug build here. Please give it a try, the usual warnings about data loss etc. when running a test build apply so use at your own risk.

[Mitlik]

The new debug apk (2.3.1) appears to open the diary to the correct date and the date selector issue is fixed. Which I believe completes this issue. I believe the regression with adding food returning to the selected home screen has also been fixed.

The alert that pops up on the stats page says "Sun Aug 12 2018 - Thu Sep 13 2018" which seems to be a rolling month through tomorrow. Maybe this fence post was necessary to get today to show up in things and fix issue #58.

[davidhealey]

Yippie! I'll wait for some others to confirm before I mark this as fixed but as long as no other issues come up I think we're there! The alert box was something I was using for testing the stats page and forgot to take it out before pushing the apk. I'll remove it before release.

[davidhealey]

I've just pushed this through as a release, let's see if it I got it right :)

[davidhealey]

Hi guys,

The last build had some new bugs and I'm not 100% certain the date issue was sorted. I've done some refactoring and made some significant under-the-hood changes and I'm hoping I've caught all these date bugs now. I've pushed a new release, if you could test and report back I'd be very grateful. I'm going to push the release to Play now so if you prefer you'll be able to download it from there soon.

[Mitlik]

I see v2.3.3 finally hit f-droid.

I've been using the v2.3.1 build you had in the thread until the update percolated through. I had so little data in the app that I had been nuking my history while testing various builds. Now I have enough data to see more of the reporting features. I'll export data and reinstall from f-droid this weekend.

[davidhealey]

There is a bug with food selection in 2.3.3 (I wish they'd gone straight to 2.3.4 but it's an automated system). It's actually a bug I thought I'd fixed a few version back so I'm not sure how it reappeared. Basically if you have two food items with the same brand in your list, selecting one of them will select the one nearest to the top of the list. It's very annoying but is fixed in 2.3.4 which will hopefully be on F-Droid soon.

[Mitlik]

Thanks for the heads up, I'll switch to 2.3.4 instead and wait for f-droid to release that (or better) before switching back to a repo install.

[davidhealey]

Thanks for the heads up, I'll switch to 2.3.4 instead and wait for f-droid to release that (or better) before switching back to a repo install.

Did you try out 2.3.4? and are you still experiencing the dates issue?

[davidhealey]

Is anyone still experiencing this issue or can I close this one now?

[Mitlik]

Fell out of using the app for a bit while I tried to figure out why import wouldn't work (I'll open an issue with findings). Been using 2.3.4 and it's pretty solid for dates. I do notice that sometimes the diary loads to the wrong date still, it's probably a UTC thing. But, entries to the diary seem to go against the correct day always so I'd say it went from major bug to very minir. I haven't tried 2.3.5 yet...

[corngood]

sometimes the diary loads to the wrong date still

Just started using the app today (2.3.7 from fdroid), and I noticed this. I am UTC-4 I think, and it seemed to default to tomorrow starting around UTC midnight, so it's probably just using the UTC date?

[davidhealey]

Thanks for reporting this. It looks like javascript dates strike again! It uses UTC + the timezone offset, but it never seems to work properly across all timezones.

Here's the exact code from the diary screen: diary.date.getTimezoneOffset() > 0 ? diary.date.setMinutes(diary.date.getTimezoneOffset()) : diary.date.setMinutes(-diary.date.getTimezoneOffset());

I'll test with your time zone and see if I can get it working. What locale are you in?

[Mitlik]

Can confirm it UTC-5

[corngood]

@davidhealey As far as I can tell, new Date() is returning local time, so I don't think the app should be taking timezone into account. I removed all those adjustments:

diff --git a/platforms/android/app/src/main/assets/www/activities/diary/js/diary.js b/platforms/android/app/src/main/assets/www/activities/diary/js/diary.js
index 5772ad16..39e14265 100755
--- a/platforms/android/app/src/main/assets/www/activities/diary/js/diary.js
+++ b/platforms/android/app/src/main/assets/www/activities/diary/js/diary.js
@@ -181,7 +181,6 @@ var diary = {
       if (diary.date == undefined)
       {
         diary.date = new Date();
-        diary.date.getTimezoneOffset() > 0 ? diary.date.setMinutes(diary.date.getTimezoneOffset()) : diary.date.setMinutes(-diary.date.getTimezoneOffset());
       }

       var categories = JSON.parse(app.storage.getItem("meal-names")); //User defined meal names are used as category names
@@ -284,7 +283,6 @@ $(document).on("show", "#diary-page", function(e){
   if (diary.date == undefined)
   {
     diary.date = new Date();
-    diary.date.getTimezoneOffset() > 0 ? diary.date.setMinutes(diary.date.getTimezoneOffset()) : diary.date.setMinutes(-diary.date.getTimezoneOffset());
   }

   diary.updateDisplayedDate();
@@ -365,7 +363,6 @@ $(document).on("keyup change", "#edit-diary-item #quantity", function(e){
 //Change date
 $(document).on("change", "#diary-page #date", function(e){
   diary.date = new Date($("#diary-page #date").val()); //Set diary object date
-  diary.date.getTimezoneOffset() > 0 ? diary.date.setMinutes(diary.date.getTimezoneOffset()) : diary.date.setMinutes(-diary.date.getTimezoneOffset());
   diary.populate();
 });

And it seemed to fix the problem for me. I tried it in the emulator with a couple of different timezones.

I printed the date and I got this: Sat Nov 10 2018 22:16:59 GMT-0600 (CST). Node and firefox both print the current time in UTC...

[davidhealey]

If that's the solution then I could kiss you! I'll try it out myself when I have some free time to work on Waistline (probably in a week or two).

[corngood]

I think there might be more fundamental problems with dates. If I change my timezone from -11 to +11, diary items will move between days. This is probably undesirable behaviour for people who are travelling. The times in the database export are all in UTC, e.g. 2018-11-11T16:43:34.548Z. That particular item will show up on 11-12 when the timezone is +11.

IMO the diary entries should never move between days after they are entered, and they should always be added to the day that's indicated at the top of the diary page regardless of the actual time when they are entered.

So should the UTC year-month-day of the db entry dictate the diary page they show up on? If that's the case maybe we shouldn't even store time for the entries?

[davidhealey]

Yes you've got right to the core of the issue. Javascript dates are screwy! I chose to index the diary items in the DB using date objects because it's faster to query the items than searching by a text string. However maybe a date text string would be a better solution... I'd have to do some kind of database migration so nobody loses their data but that shouldn't be too difficult. What do you think of this idea? or do you have a better suggestion?

[corngood]

I don't think I'd bother switching to text. Text dates would probably be more work and just as fragile as date objects. As long as everything's well defined I think it's fine to use date objects in the DB.

I need to read up on the js Date object a bit more before I suggest anything detailed.

Does anything currently use the time of day stored in the diary? I can imagine some interesting uses of it, like a graph of calories throughout the day, or auto assigning meals, but it could be really tricky to get right when the user can change timezones.

[davidhealey]

No the time isn't used. In fact a few versions ago I had it set up so that the date would always be midnight in the hope it would prevent these date issues but it didn't make much difference.

[corngood]

I tried to go through all the places dates are used and make sure it's all using UTC, see:

https://github.com/corngood/waistline/commit/b4be6306188f655f3f4b8cdf78524e8b613c8f7d

I think it's still going to need a database migration, because some diary entries weren't being added to the current UTC day. I'll look at that next, and make a PR after I deal with that and do a bit more testing.