Jump to content

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.

Link to comment
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
Link to comment
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.

Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment

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
Link to comment

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

Link to comment

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
Link to comment
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
Link to comment
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
Link to comment

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
Link to comment
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 :-)

Link to comment

Hi.

We think your recent fix to GPX files may have caused a problem with GSAK, iCaching, and other programs that display the cache hidden on date. I started a discussion here about that: 

There's another issue unrelated to the GPX issue in that the time sent to my calendar is off by an hour. That is, the time zone stamp doesn't seem to include daylight savings time. I don't know if that's because a time zone is stamped to the event at the time of creation or submission rather than according to the date of the event, and these events were created before the time shift, or if the time zone lookup just doesn't include daylight savings time. Either way, the time displayed on the cache page is correct and likely the same time entered in by the CO, but the time being pushed to my calendar is currently one hour behind. As new events get published, I'll check to see if the timing is still off. It's still a bug worth looking into.

Times are otherwise correct for the time zone of the event. An event in Maryland that starts at 5:00pm (Eastern Daylight Time) will create a Google Calendar event that starts at 1:00 pm in Pacific Standard Time (not 2:00 Pacific Daylight Time).

Edited by Mineral2
Link to comment
22 minutes ago, Mineral2 said:

There's another issue unrelated to the GPX issue in that the time sent to my calendar is off by an hour. That is, the time zone stamp doesn't seem to include daylight savings time. I don't know if that's because a time zone is stamped to the event at the time of creation or submission rather than according to the date of the event, and these events were created before the time shift, or if the time zone lookup just doesn't include daylight savings time. Either way, the time displayed on the cache page is correct and likely the same time entered in by the CO, but the time being pushed to my calendar is currently one hour behind. As new events get published, I'll check to see if the timing is still off. It's still a bug worth looking into.

Times are otherwise correct for the time zone of the event. An event in Maryland that starts at 5:00pm (Eastern Daylight Time) will create a Google Calendar event that starts at 1:00 pm in Pacific Standard Time (not 2:00 Pacific Daylight Time).

I think it's still an issue for events created since the time change. I just checked one that was published two days ago, and it shows as one hour too early when I export it to my Google Calendar. Likewise with the "Outlook / iCal" export.

Link to comment

It's only been a week since DST took effect. It's possible that the event was first created before DST, then sent for review just before or just after, and the reviewer just got around to publishing it. I'm not ready to commit to a particular event right now, or I'd create and have one published myself. But as we get through the month, new events will certainly have been created after the time change. Meanwhile, someone at HQ can look at the code to see how and when the time zone is being looked up for the calendar data files.

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...