Jump to content
Sign in to follow this  
Followers 9
Geocaching HQ

Release Notes (Website: Event start and end times) - January 15, 2019

Recommended Posts

41 minutes ago, Viajero Perdido said:

PS, at the top of the event page, why is time not right beside (or underneath) date?  Conceptually, they belong together, no?

 

Placing the event date on the same line as the time was initially presented by the team. However, the current layout was chosen because it maintains a consistent layout with non-event caches. During this transition period there are still events with no time selected and the layout was confusing when the date was on a separate line without the time.

Share this post


Link to post
6 hours ago, HiddenGnome said:
7 hours ago, Viajero Perdido said:

PS, at the top of the event page, why is time not right beside (or underneath) date?  Conceptually, they belong together, no?

 

Placing the event date on the same line as the time was initially presented by the team. However, the current layout was chosen because it maintains a consistent layout with non-event caches. During this transition period there are still events with no time selected and the layout was confusing when the date was on a separate line without the time.

 

I agree with VP and think, still, that something like the following would make the Event Cache pages more user-friendly.

 

The date for non-event caches does not reflect the same type of information as does the date for event caches.  Non-event caches emphasize a past date (when the cache was hidden), while event caches emphasize a future date (when the event occurs) - so it would seem that it's more important to have dates and times placed together for Event caches, regardless of the layout for non-event caches.  The page layouts are already different because non-event caches do not have any time fields, so the layouts are going to differ regardless.  Keeping the most essential aspect of Event pages, date and time of event, together on the page would seem like the better layout.

 

image.png.420a3482bd2468e04941f5727855bcc7.png

 

  • Upvote 4

Share this post


Link to post

Good points above.

 

Also, four "filler" words (start time end time) could be replaced with a simple hyphen for easier parsing.  Millions of people scanning event pages to find the critical detail of time, multiplied by a second or two each, well, it adds up.

 

Edited by Viajero Perdido
  • Upvote 1

Share this post


Link to post
14 minutes ago, Viajero Perdido said:

Also, four "filler" words (start time end time) could be replaced with a simple hyphen for easier parsing.  Millions of people scanning event pages to find the critical detail of time, multiplied by a second or two each, well, it adds up.

 

Yes.  One of my examples has "event time" instead of  start / end  times.  Keeping it simple would certainly make it easier to read.

Share this post


Link to post
17 hours ago, MartyBartfast said:

Not sure whether this is related to this release but....

 

This event https://coord.info/GC81NMH  is happening  5:00pm to 8:00pm on Janary 30th. But when using "Add to Calendar" to add to Outlook via a .vcs card it creates an Outlook entry for 01:00 am on January 31st 

 

10 hours ago, The A-Team said:

This seems to be the same issue as platoaddict mentioned. The site seems to be assuming that the event time is in the Seattle time zone (Pacific time), rather than using the time zone of the event location. I just compared the VCS file from this event and one local to me in the Pacific time zone, and both show a UTC time based on the assumption that the time submitted on the listing is in the Pacific time zone.

 

If automated time zone detection is too difficult or prone to mistakes, the logical next step would be to provide a time zone selector alongside the event time fields when editing the listing.

Please can this be resolved as soon as possible. I look at events through GSAK and they now have the wrong date . This bug has been introduced by the latest changes and should be given very high priority. 

  • Upvote 1

Share this post


Link to post
On 1/16/2019 at 7:37 AM, thomfre said:

 

  1. Please add option for time format to the user preference page, I don't want times to show in 12-hour format

Even though the site is maintained in the USA it should be realised that the majority of countries use a 24 hour clock. Hence any date time functionality should allow nationalisation preferences and also be tested as such. The vast majority of multi-national internet applications do just that.

  • Upvote 2

Share this post


Link to post
1 hour ago, lodgebarn said:

Please can this be resolved as soon as possible.

Just make sure you get the right day  and I'll buy you a pint :omnomnom: ('cos there's no Signal supping beer).

  • Funny 2

Share this post


Link to post
11 hours ago, lodgebarn said:

 

Please can this be resolved as soon as possible. I look at events through GSAK and they now have the wrong date . This bug has been introduced by the latest changes and should be given very high priority. 

The problem is that GPX files (from cache page or PQ) deliver the date one way, and the API (Get or Refresh Cache) a differerent way.  In GSAK all you have to do currently (which is a step we shouldn't have to take) is refresh the cache using the API and the correct date should display.

  • Helpful 1

Share this post


Link to post
1 hour ago, The Jester said:

The problem is that GPX files (from cache page or PQ) deliver the date one way, and the API (Get or Refresh Cache) a differerent way.  In GSAK all you have to do currently (which is a step we shouldn't have to take) is refresh the cache using the API and the correct date should display.

Yes but the PQ is the wrong date so should be resolved, it worked fine before. This feature is flawed and should be fixed...

  • Upvote 2

Share this post


Link to post
1 hour ago, lodgebarn said:

Yes but the PQ is the wrong date so should be resolved, it worked fine before. This feature is flawed and should be fixed...

I agree 100%.  This is ongoing problem that Ground Speak has had.  I was just suggesting a work around for GSAK users until it's corrected.

  • Upvote 2

Share this post


Link to post
2 hours ago, lodgebarn said:
3 hours ago, The Jester said:

The problem is that GPX files (from cache page or PQ) deliver the date one way, and the API (Get or Refresh Cache) a differerent way.  In GSAK all you have to do currently (which is a step we shouldn't have to take) is refresh the cache using the API and the correct date should display.

Yes but the PQ is the wrong date so should be resolved, it worked fine before. This feature is flawed and should be fixed...

The hidden date / event date field on the cache page seems to use the <time> field in the gpx files.

For non-event caches, the <time> field seems to be either 07:00Z or 08:00Z (midnight in HQ time, with the hour difference presumably based on DST).  I'm guessing that is what programs like GSAK and GPSr's are expecting so that the user sees the date appropriate to their time zone.

  • For current event caches that don't have start/end times, the <time> field still seems to follow that rule, showing 08:00Z now.
    • Whether the event cache is in Seattle or Norway, the event <time> shows 08:00Z.
  • For current event caches that do have start/end times, the <time> field seems to be populated differently.  The Zulu time of the event is being populated, but it's reading the time as if it's in Seattle.
    • A 1pm event in Seattle shows <time> of 21:00Z, which is 1pm in Seattle.
    • A 1pm event in Norway also shows <time> of 21:00Z, which is not 1pm in Norway.

 

Maybe it would be better if the <time> field was populated the same way for all Event caches, regardless of whether the start/end times are populated or not.  And show all <time> as 08:00Z or midnight.  The GPX files aren't showing the start/end times, so there doesn't seem to be any gain from populating <time> differently.  It's just causing problems for cachers in other time zones.

 

Edited by noncentric
  • Upvote 1
  • Love 1

Share this post


Link to post
17 hours ago, The Jester said:

I agree 100%.  This is ongoing problem that Ground Speak has had.  I was just suggesting a work around for GSAK users until it's corrected.

Thanks, trouble is that most of my data comes from PQs and I look at the placed date for event info. The problem will only get worse as more events are added with the new feature. I am most disappointed that no-one  from Groundspeak can be bothered to add to the discussion.

  • Upvote 1
  • Helpful 1
  • Love 1

Share this post


Link to post

Thank you for all the feedback in this thread. We are reading this thread and documenting the feature requests and bugs.


Of the bugs that have been identified, two are now fixed:

  • Event Caches created in Firefox using the 12 hour format no longer show a date of NaN Invalid Date NaN.
  • GPX files downloaded from the cache page no longer show the incorrect time (and date). Instead they are showing the time entered by the CO without a specified time zone.

The fix for the GPX files downloaded from the cache page did not fix the similar issue with GPX files from PQs. We are looking into that next and will update this thread when the fix goes out.
 

  • Upvote 1
  • Helpful 2

Share this post


Link to post

Hello developers,

moved this entry from another thread, this is the better place.

 

The function "adding the event date and time to my calendar" is great, but ...
 - we are in Germany with MEZ (UTC+1h) at winter and MESZ (UTC+2h) in summer.
 - the fields Start time and End time in the list heading show the correct time,
   for example "Start time 12:00 PM End time 12:30 PM"
 - I choose "Add To Calendar" with OUTLOOK / iCal
 => my outlook shows start time 21:00 and end time 21:00

 

I looked in the vcs file for this download to calendar and found
"DTSTART:20190219T200000Z" equal to 21:00 MEZ
"DTEND:20190219T200000Z"   equal to 21:00 MEZ


But this fields should show
"DTSTART:20190219T110000Z" equal to 12:00 MEZ
"DTEND:20190219T113000Z"   equal to 12:30 MEZ

for a correct entry to Outlook/iCal.

 

I think there is a bug and it should be corrected.

 

Regards, teddy.66

Share this post


Link to post

Can you please remove the default values?

Here is another fine example (I have many, if that's what you need): https://coord.info/GC81NTW
Midnight to 1pm in the event time field, but noon to sunset (nice times🙄) in the description.

  • Upvote 2

Share this post


Link to post

Yes, trying to get people to use the new time feature won't work if you leave default values that clearly conflict with actual event times. No one will trust the time field. Yep, making it required means a person will have an extra step. But they are creating an event listing. There are many required steps. A specific time is already needed; should reviewers be the ones now to also make sure the time in the description matches the time in the time fields? erk...

  • Upvote 1

Share this post


Link to post

With defaults enabled, you temporarily get an error message between entering the two times manually.  (End must be after beginning, or somesuch.)

 

Behavior like that from a human would be considered rude.  From a computer, we just expect it.

Share this post


Link to post
9 hours ago, thomfre said:

Can you please remove the default values?

Here is another fine example (I have many, if that's what you need): https://coord.info/GC81NTW
Midnight to 1pm in the event time field, but noon to sunset (nice times🙄) in the description.

 

We are prioritizing removing the default values and requiring owners to select specific times in our future work. Most events that show up with inconsistent times are events that owners created before January 15 and have since edited, not noticing the new time fields. We reach out to COs when we know of an event with a time discrepancy, and believe that most people will not show up at midnight without first reading the event description.

  • Upvote 1

Share this post


Link to post
3 hours ago, hleeful said:

 

We are prioritizing removing the default values and requiring owners to select specific times in our future work. Most events that show up with inconsistent times are events that owners created before January 15 and have since edited, not noticing the new time fields. We reach out to COs when we know of an event with a time discrepancy, and believe that most people will not show up at midnight without first reading the event description.

The problem here is "most events". Since there's so many events that have a mismatch between the new time and the time in the description, you can't really trust any of them. This is making it harder to figure out the actual time of the events. And it was already hard (it's amazing how hard some people hide the event times) without this.

Thank you for giving this priority.

  • Upvote 2

Share this post


Link to post

We have just released a fix to the Add To Calendar feature on website cache pages:

  • The Google Calendar and Outlook/iCal links are now updated.

  • Events with event times are now added to the calendar in the time zone of the event.

  • When you add an event from another time zone to your calendar, the event will show on your calendar at the time that it will happen in the time zone of the event — for example: If you are in Germany and you add an event in Seattle to your calendar, the event will show on your calendar at the time of the event in Seattle time, 9 hours earlier than the event time - because Seattle is in a time zone 9 hours earlier than Germany.

  • Your time zone is based on the time zone preference in your Geocaching.com profile.

  • Upvote 1
  • Helpful 1

Share this post


Link to post
On 2/15/2019 at 9:06 PM, nykkole said:

We have just released a fix to the Add To Calendar feature on website cache pages:

  • The Google Calendar and Outlook/iCal links are now updated.

  • Events with event times are now added to the calendar in the time zone of the event.

  • When you add an event from another time zone to your calendar, the event will show on your calendar at the time that it will happen in the time zone of the event — for example: If you are in Germany and you add an event in Seattle to your calendar, the event will show on your calendar at the time of the event in Seattle time, 9 hours earlier than the event time - because Seattle is in a time zone 9 hours earlier than Germany.

  • Your time zone is based on the time zone preference in your Geocaching.com profile.

Many thanks, now Outlook/iCal works fine :-)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
Followers 9

×