Who is aware of the north american time zone the pocket query servers work? [closed]

Question

In my case it was not possible to start a pocket query on a certain day, because the pocket query servers in the USA follow their own time zone.

Example: here in Germany we are 9 hours "later" than in the pacific timezone and this leads to:

All queries which are started on a saturday morning before 9:00 o'clock and checked for execution on Saturday will not execute before saturday is reached in the pacific timezone. This is the case at 9:00 o'clock CET. When knowing this helps you to overcome the problem: you simply must check the box to execute these queries on friday.

My additional idea is to speak with geocaching.com, to explain this problem, and ask them for a workaround.

Answer 1

I suspect that most that used PQ know that. If you create a new PQ there is a "Pocket Query Tips:" on the bottom of the page. 

Pocket Queries are generated in Pacific Standard Time (PST). This may mean that your Monday is different from our Monday.

There is a server time clock on the PQ page for that reason

The reason is quite obvious because it makes scheduling of PQ simpler on the server if only one time zone is used. The PQ system and the notification is likely the one oldest part of the website still in use. If I dont miss remember one of the founders that wrote the original code said when he talked on a mega event that those part are the only part that still use the original code.

You could post a suggestion on the groundspeek forum but I would not expect it to change. The more annoying problem with the legacy code is that you cant set any cache type for notification, the change have been requested since I started 6 yeas ago and had not change. Groundspeek tries to move away from PQ and handheld GPS to API and phone apps if you look at their changes. A extention to the GPX format was in the works a few years ago and was delayed an have not been done to this day- Rewriting the scheduling for PQs are likely extremely low on their priority when you can compensate by changing the day to the day before if you need it in the morning.

There was a similar problem with when the date of a log in the apps would get the date of the server and not the date of the user and it took the a long time to fix that and that was a problem.

Answer 2

If you want the freshest data in the shortest time, then just create a new PQ of the wanted area. Set it to run once and you will get the results within minutes.

New PQ's have higher prority than already used PQ's. And in the queue of used PQ's  e.g. the ones that were run half a year ago are higher priority than the ones that run last week.

Answer 3

I fully understand the answer given by Target yesterday.

I will use the known workaround as described - there is no need to redesign "old" code which works great when compared with other stuff.