Bug: Date problem when using filter

[+funkymunkyzone]

This is annoying for trying to search for caches hidden between certain dates.

 

I open the filter and choose my dates:

 

 

I apply them and look at the map.  If I go back to the filter, I can see that it has changed the dates and not searched for the period of time I wanted:

 

Why does the website think I want different dates than what I actually selected?

 

 

[+capoaira]

This bug is really annoying and exists since months. (I recognised the bug in March 2022)

The workaround is to always set the day one after. 

 

It would be nice if the engineers can fix it.

[+Picht]

Hi

 

When going to Play -> View Map and selecting a filter there is an issue with the dates.

I select Placed date between Feb/1/2022 and Feb/28/2022 and press Apply.

Then I press Filter again. Now the 2 date fields have these dates: Jan/31/2022 and Feb/27/2022

It seems as if the filtering is 1 day off.

Using Firefox and Edge on Win 10

Living in Europe with Timezone UTC+1

 

/Picht

Edited March 7, 2023 by Picht

[+TeamRabbitRun]

Seeing as how all three of you are many timezones away from Seattle, it COULD have something to do with the fact that when it's 4:00 AM in, for example Germany, it's still the previous day in Seattle, where the searching is actually being done.

 

Complex stuff, entertaining time-based queries from around the world. I'm not going to injure my brain right now with a long discussion on the permutations of managing world-wide inquiries and delivering accurate results, especially when GS doesn't know the 'local timezone' settings on all of your PCs.

 

Try testing this at two times-of-day:

• When it's a day where you are but still the previous day in Seattle,
• When it's the same day where you are AND in Seattle.

 

Then, check your PC's timezone settings. (In Windows; I don't know what any other operating system does!)

 

THEN you'll have a better idea of possible causes. Don't know whether or not it'll do you any good, but you'll know more.

 

 

 

Edited March 7, 2023 by TeamRabbitRun

[+barefootjeff]

2 hours ago, TeamRabbitRun said:

Seeing as how all three of you are many timezones away from Seattle, it COULD have something to do with the fact that when it's 4:00 AM in, for example Germany, it's still the previous day in Seattle, where the searching is actually being done.

 

Complex stuff, entertaining time-based queries from around the world. I'm not going to injure my brain right now with a long discussion on the permutations of managing world-wide inquiries and delivering accurate results, especially when GS doesn't know the 'local timezone' settings on all of your PCs.

 

It shouldn't have anything to do with timezones. All caches have a Date Placed field which is set up when the cache is created:

 

If you search for caches placed on a particular date, such as:

 

 

it ought to be just matching up caches in the database with a matching Date Placed field. Yet what happens, every time, is the search date gets bumped back one day when the search is run, so it returns caches with a Date Placed of the 3rd of March.

 

 

 

 

 

 

[+TeamRabbitRun]

20 hours ago, barefootjeff said:

 

It shouldn't have anything to do with timezones. All caches have a Date Placed field which is set up when the cache is created:

 

If you search for caches placed on a particular date, such as:

 

 

it ought to be just matching up caches in the database with a matching Date Placed field. Yet what happens, every time, is the search date gets bumped back one day when the search is run, so it returns caches with a Date Placed of the 3rd of March.

 

 

 

 

 

 

 

 

Gently pushing back, Jeff - but it MIGHT indeed.

 

All 'times' in GS' database are either stored in Seattle-local time or UTC/GMT, the world-wide standard: the time in Greenwich, England, longitude zero.

'Seattle time' would not be my choice, but in the year 2000, maybe they really didn't think this would take off so broadly, and just programmed a little local application. I suspect not, or that it would have been upgraded at some point since then, otherwise there would have been MANY more bugs surfacing.

 

So, UTC, then. That means that there needs to be a translation on both ends: once when a cache is placed, converting a cacher's local time to UTC for storage, and one more on an inquiry. Those translations are typically done by the PC, according to the 'time' settings.

 

Consider this case (boy, I must be bored today):

You plant a cache at 6PM YOUR time, and immediately tell your friend about it, on the other side of the planet. For you, it's today. Where your friend is, across the International Date Line, it's still yesterday from your point of view. If he immediately looks at your cache online, what date appears on it? Today (to them), or tomorrow (to them)?

 

So, another friend, who lives with the first friend, shares a GC account. That second friend is visiting you, and is FTF on the cache just after it's planted and approved (fast reviewer!). 

 

Friend 2 either logs it on the spot, or talks to friend 1 back home and has HIM log it. In either case, what date shows up on the log: yesterday, today or tomorrow?

 

What if a cache-local guy shows up an hour later and logs it AFTER friend 1 logs it back home? Who's log appears first on the page?

 

Using UTC time is SUPPOSED to allow you to manage all this michegas, but if the programmers don't consider ALL of this kinda stuff while developing every step of a workflow, then chaos rules.

 

On a related issue, I once wrote a paper back in school long, long ago discussing whether or not Phileas Fogg actually won that bet.

 

(Yep, bored.)

 

 

 

Edited March 8, 2023 by TeamRabbitRun