Jump to content

date of log in IPhone app


pantadeusz

Recommended Posts

Hey, I got used to the fact that the IPhone app, which I use to log the vast majority of my caches, works on American time and therefore, if I want to log a cache with today's date, I need to do it after 7am Irish time (before the change to winter time it used to be 8am). Or so I thought. Because today I logged a cache at around 7.15-7.20am and it came up with yesterday's date. But I also retrieved a trackable from it and logged it around 30 seconds later, and that came up with today's date already. Does anyone have a detailed understanding of how the date is assigned to a log by the app?

 

Screenshot_from_2016_11_14_08_20_05.png

Link to comment

So no one knows?

 

There were many posts over the past couple weeks about issues with time/date when posting from the site, app and field notes. It might be resolved now so test it with a new cache tomorrow and see if it's working as you expect.

 

Another option to consider is purchasing a 3rd party app that allows the log date to be select in the app.

Link to comment

So no one knows?

 

There were many posts over the past couple weeks about issues with time/date when posting from the site, app and field notes. It might be resolved now so test it with a new cache tomorrow and see if it's working as you expect.

 

Another option to consider is purchasing a 3rd party app that allows the log date to be select in the app.

All good, but this is a separate point and it's not related to my question. I want to know how this app works exactly.

Link to comment

[All good, but this is a separate point and it's not related to my question. I want to know how this app works exactly.

The official app will post based on PT time (US West Coast) which is UTC -8 during this time of year. Your original post indicated that is what you expected but when you posted there were various date/time issues. Is it still an issue?

Link to comment

I don't think it is so simple. I say that because I have just logged a trackable and, a few minutes later, a cache, both using the app. Interestingly, the trackable, logged earlier, comes with todays date, but the cache, logged later, comes with yesterdays date. So whatever the system is for the trackables, it is different from the system for caches, and different in a way which I would prefer to use for caches as well. Is there any way to actually look at the actual algorithm which assigns dates to logs in the app? It looks like there is an inconsistency there and in any case, the system for caches should be improved to assign correct dates in all timezones, not just in America.IMG_5527.png

Edited by pantadeusz
Link to comment

Yes, 'under the hood', as they say, there may be multiple methods of submitting dates with logs (cache and trackable). There are pre-API methods and API-specific methods.

What should happen is unnoticeable. The date locally (in-app) would be your local timezone, but the system should recognize the timezone submitted and save/alter the display of field notes as necessary and seemless. (the final logs online don't include a timezone, only a date, so timestamps are stripped from field notes and whatnot; which does help by not having to deal with timezones on the whole website scale).

 

eg: Cache log and TB log dated Dec.15/2016 at 8pm EST should be stored locally in-app with the correct timezone. Since there are no TB field notes, but they are actually posted immediately, on submitting the logs the cache log may get converted to HQ timezone PST while the TB log would be posted as of the date part, not the time part (what you would expect for your local time). But there seems to be a problem with the storage of cache field note timestamps after being submitted (likely) by some older method in the app.

 

Ideally, any field note date/time would be displayed as in your local timezone. But something's messed up somewhere in this process.

 

As of right now, there still seems to be an inconsistency with at least one method amongst the various means of submitting logs from various sources/app.

 

I'm of the belief that it's an "old" method of log submission to field notes they no longer wish to support, and unless they're currently working on it to fix it (I'd like to think so), then they may be shrugging it off as obsolete and any apps that still use it having not updated to the API are just simply out of luck. I truly hope the latter is not the case. (even if their old official app is also having problems)

Edited by thebruce0
Link to comment

The more I think about the whole date/time/time zone issue, the more I think that it's unnecessary to fool around with time zones at all and that the whole process could be significantly simplified.

 

In the end, what's the one important piece of date/time information you need about the log so it can be displayed on the website and in the apps? The date. It's irrelevant what time a log is created. Ordering of the logs on the same date can be done by the unique GL code that's automatically assigned in order to each new log. Therefore, logs would be displayed in the order they were created, which makes sense.

 

By cutting out the headache of trying to convert between time zones, all an app needs to do is determine the current date (or a manually-selected date, which some apps offer) and use that. As long as the user's device has the right date set, this should be straightforward and unlikely to go wrong unless the user is logging right around midnight in their time zone.

 

To do this would likely require a not-insignificant change to the main database, because all existing logs are recorded with a date and time, but it would greatly simplify things going forward.

 

Just a thought.

Link to comment

The more I think about the whole date/time/time zone issue, the more I think that it's unnecessary to fool around with time zones at all and that the whole process could be significantly simplified.

 

In the end, what's the one important piece of date/time information you need about the log so it can be displayed on the website and in the apps? The date. It's irrelevant what time a log is created. Ordering of the logs on the same date can be done by the unique GL code that's automatically assigned in order to each new log. Therefore, logs would be displayed in the order they were created, which makes sense.

 

By cutting out the headache of trying to convert between time zones, all an app needs to do is determine the current date (or a manually-selected date, which some apps offer) and use that. As long as the user's device has the right date set, this should be straightforward and unlikely to go wrong unless the user is logging right around midnight in their time zone.

 

To do this would likely require a not-insignificant change to the main database, because all existing logs are recorded with a date and time, but it would greatly simplify things going forward.

 

Just a thought.

 

I think you've overcomplicated the situation. The date/time should be stored as GMT/UTC. Seems like this is being done based on the API. What then needs to occur is web site/app dependent function showing either UTC/GMT or a timezone specific representation. An app knows your timezone and any website can do it either using a setting like GC already has available or leveraging the browser to determine local TZ.

Link to comment

The more I think about the whole date/time/time zone issue, the more I think that it's unnecessary to fool around with time zones at all and that the whole process could be significantly simplified.

 

In the end, what's the one important piece of date/time information you need about the log so it can be displayed on the website and in the apps? The date. It's irrelevant what time a log is created. Ordering of the logs on the same date can be done by the unique GL code that's automatically assigned in order to each new log. Therefore, logs would be displayed in the order they were created, which makes sense.

 

By cutting out the headache of trying to convert between time zones, all an app needs to do is determine the current date (or a manually-selected date, which some apps offer) and use that. As long as the user's device has the right date set, this should be straightforward and unlikely to go wrong unless the user is logging right around midnight in their time zone.

 

To do this would likely require a not-insignificant change to the main database, because all existing logs are recorded with a date and time, but it would greatly simplify things going forward.

 

Just a thought.

I think you've overcomplicated the situation. The date/time should be stored as GMT/UTC. Seems like this is being done based on the API. What then needs to occur is web site/app dependent function showing either UTC/GMT or a timezone specific representation. An app knows your timezone and any website can do it either using a setting like GC already has available or leveraging the browser to determine local TZ.

Why bother with the time zones at all, though? If you're converting between time zones and viewing a log in a different time zone than it was created in, a log may be displayed with a different date than when it was actually found. Wouldn't that be undesirable?

 

I guess what I'm asking is: if I submit a log at 1200 PST (UTC-8) on December 20th for a cache in Seattle, and someone in China (UTC+8) views the log, what date should it display? The local date on which the find was made (Dec 20), or the converted date which would be displayed as a day later than the local date of the find (Dec 21)? Personally, the latter would make no sense to me, but that seems to be the behaviour you're describing. What I'm saying is that if it always used the local date, then the time and time zone information wouldn't need to be stored or compensated for at all.

Link to comment

Why bother with the time zones at all, though? If you're converting between time zones and viewing a log in a different time zone than it was created in, a log may be displayed with a different date than when it was actually found. Wouldn't that be undesirable?

 

I guess what I'm asking is: if I submit a log at 1200 PST (UTC-8) on December 20th for a cache in Seattle, and someone in China (UTC+8) views the log, what date should it display? The local date on which the find was made (Dec 20), or the converted date which would be displayed as a day later than the local date of the find (Dec 21)? Personally, the latter would make no sense to me, but that seems to be the behaviour you're describing. What I'm saying is that if it always used the local date, then the time and time zone information wouldn't need to be stored or compensated for at all.

 

I'd expect all dates to either be UTC or my local timezone.

 

If someone in Australia logged a cache right about now, it would be:

9:55am AEDT Weds Dec 21, 2016 <--- Local time of the cacher logging the find

10:55pm UTC (2255z) Tues Dec 20, 2016 <--- UTC time

5:55pm EST Tues Dec 2016 <--- Local time for me

 

I would expect to see that the cacher in Australia logged it at 5:55pm my time or 2255z.

 

Wouldn't it be odd to me to see something logged tomorrow?

 

 

Link to comment

The times aren't actually stored with the final logs, and A-Team that's exactly how logs are ordered on cache listings - by date, then LogID (try deleting a log then reposting it on the same date, it suddenly appears as the most recent on that date). The problem is only with the Field Notes. The problem lies when the timestamp of a log/note (imported via whatever mobile app or application) is converted to online Field Note timestamp (currently being mis-adjusted by +8 hours) - if it rolls over a date, then when you Compose that field note to a Log, the date is wrong (timestamp is simply stripped from the date) and can mess people up.

 

Everything else in the process is fine.

 

Post a Log directly, and the source uses the localized date - no timezone conversion. TB logs? Same thing, since there's no TB Field Note, the log is posted immediately by the date stored in the source app, regardless of timezone. It's only when converting data to an online Field Note that timezones seem to be an issue.

 

Uploading as Field Notes via the API doesn't seem to have a problem.

It looks like any app that uploads the 'old' way seems to have the problem.

 

eg:

App stores a mobile note for a cache on 12/15/2016 at 11:00pm EST (GMT-5).

* Upload as a Log? The log is date defaults to 12/15/2016

* Upload as a Field Note? Conversion is currently awry and the note would be dated 12/16/16 7:00am (note: no timezone is shown on the Field Notes page). When you compose, the Log date incorrectly defaults to 12/16/2016.

 

This may be the issue - somewhere in this process the timezone is being stripped from the date that's submitted, before any conversion to GMT (or PST if they store in Seattle time) takes place (my 11:00pm time would be assumed as PST). Thus all field note times get bumped the +8 hours between PST and GMT, so it shows on the Field Notes page +8 hours for anyone anywhere in the world.

Edited by thebruce0
Link to comment

Wouldn't it be odd to me to see something logged tomorrow?

I guess this is where we have a difference of opinion. Personally, it would be completely reasonable to me to see a log dated as tomorrow if it was around the other side of the world. I'd actually find it more confusing if someone had found a cache on one date, but it was displayed to me as a different date.

Link to comment

...

Everything else in the process is fine.

...

It's only when converting data to an online Field Note that timezones seem to be an issue.

These forums are riddled with people complaining about their app logging their find with the wrong date. It isn't just about field notes. As someone who lives in the Eastern time zone, if you submitted a log at 10 pm, the log would show up on the cache page with the wrong date.

Link to comment

...

Everything else in the process is fine.

...

It's only when converting data to an online Field Note that timezones seem to be an issue.

These forums are riddled with people complaining about their app logging their find with the wrong date. It isn't just about field notes. As someone who lives in the Eastern time zone, if you submitted a log at 10 pm, the log would show up on the cache page with the wrong date.

 

Do you have a link to a good thread discussion? I'd be interested to know if that's in any way related to the field notes issue which only just showed up a couple of weeks ago or so.

Link to comment

Gah, ok, for pantadeusz: Can you describe if you used Field Notes to compose the cache log (if in the app you uploaded the find log attached with the TB log but had the Find posted to Field Notes), or if you posted it directly as a Log from the app?

I jumped to that assumption coming in from comment #4 that had me thinking along the line of Field Notes from the start :)

Link to comment

The times aren't actually stored with the final logs, and A-Team that's exactly how logs are ordered on cache listings - by date, then LogID (try deleting a log then reposting it on the same date, it suddenly appears as the most recent on that date).

The cache log? If you log through the website there's effectively no time saved (it's saved as noon PST/PDT), if you log through the API the time is saved as UTC. You can see this by exporting your finds and looking at the XML.

Link to comment

The times aren't actually stored with the final logs, and A-Team that's exactly how logs are ordered on cache listings - by date, then LogID (try deleting a log then reposting it on the same date, it suddenly appears as the most recent on that date).

The cache log? If you log through the website there's effectively no time saved (it's saved as noon PST/PDT), if you log through the API the time is saved as UTC. You can see this by exporting your finds and looking at the XML.

Rrrriiiiiight... completely forgot about that.

 

Ideally, there will always be inconsistencies if some active methods exist that strip or don't request the time/zone (like web), and some exist that include the timezone. To be clean, the system has to be all or nothing.

1. Either strip the timezone from all log saves and keep the date static (meaning the best way to interpret the date when reading would likely be to infer it's as of the cache listing's local time, or the finder's local time, if it's really that important since there'd be no timezone conversion to the reader's time across the globe), or else

2. Allow a timestamp for all submission methods so that there are no time-less dates just 'assumed' to be midnight GMT (as in web) which would be subject to incorrect date display after timezone adjustment. Unless...time-less datestamps are flagged as static so timezone is irrelevant and the date is treated as in the former option. But implementing that would be extra work system-wide to handle two types of datestamps for a minor problem.

 

Anyway... regardless of that, there are still blaring timezone problems; at least one that is brand new, and not just based on the fundamental problem with the log date/time storage strategy.

 

Timezone issues have existed for years (I remember discussions about it beta testing Geosphere too for interaction with GC). The field note +8hour one (which may well be different than this thread) just showed up recently.

Link to comment

Gah, ok, for pantadeusz: Can you describe if you used Field Notes to compose the cache log (if in the app you uploaded the find log attached with the TB log but had the Find posted to Field Notes), or if you posted it directly as a Log from the app?

I jumped to that assumption coming in from comment #4 that had me thinking along the line of Field Notes from the start :)

Sorry, I think there is some confusion here that I don't understand. I don't really know what field notes are (but would be happy to find out). I logged the TB first, finding it by its code. Then I logged the geocache. The two were separate logs.

Link to comment

Gah, ok, for pantadeusz: Can you describe if you used Field Notes to compose the cache log (if in the app you uploaded the find log attached with the TB log but had the Find posted to Field Notes), or if you posted it directly as a Log from the app?

I jumped to that assumption coming in from comment #4 that had me thinking along the line of Field Notes from the start :)

Sorry, I think there is some confusion here that I don't understand. I don't really know what field notes are (but would be happy to find out). I logged the TB first, finding it by its code. Then I logged the geocache. The two were separate logs.

 

Ok so the TB would be live, but if you have no idea what field notes are then don't worry about it, you'd have posted the Log live. So that's not necessarily the exact same issue. (though it may still be related, but as mentioned Log dating with timezones has had issues for some time)

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...