Jump to content

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


Recommended Posts

Release Notes (Website: Event start and end times) - January 15, 2019
 
With today’s release, we are adding the functionality to add start and end times to Event Caches.

 

Cache owners can now input their event times during the Cache Submission Process (CSP) and update them on the edit page. Players can see the event times at the top of the Event Cache page on Geocaching.com, as well as in the description.

 

CSP and edit page

 

  • Cache owners have the option to input times in either 24-hour or 12-hour formats.
  • The new feature enforces the minimum event time from the guidelines (30 minutes for regular events, and 1 hour for CITO events).
  • An event can start any time between 00:00 and 23:15.
  • The latest possible end time for an event is 23:45 — this is a current limitation since midnight would technically be on the next day, but events can only happen on one day.

 

zCwZ4jv4ydm79Vq-UNb-Zqh3xNGd0F3xXZVFOXpw

 

Event cache page on Geocaching.com


Event Cache pages show the event time at the top of the page, under the event name. 
The time format is based on the player's language settings. 
For example, if you set your language to English, you will see the time in 12-hour format, because we set the locale to "en-US" for English. This means it's displayed incorrectly for a British player right now. If you set your language to Spanish, for example, you will see the time in the 24-hour format.

 

j_iTPjZjWo5Wlq-XhGOkr2Oolj9etFcknKI78ze6

 
 

Event cache description

  • The event date and times are also automatically added to the top of the description. This is currently done in the following format: 06 March 2019, 19:00 - 19:45. The date month will be shown in English and the time will be shown in 24 hour time. It is currently not possible to translate the month or change the time format. This is intended to be an interim solution so the date and time will show up in GPS devices, the Geocaching® app, and partner API programs right away. Cache owners cannot edit this section of the description.

 
After a testing period, we will reassess this feature and what updates or changes to make.
 
Heather W. (hleeful), Senior Software Developer, and Nicole J. (nykkole) Community Volunteer Support Lead are watching this thread to answer questions whenever possible.
 
Any posts in this thread should relate to features in this release. Comments unrelated to the release may be removed. Please direct unrelated comments to other appropriate threads. Thanks!

  • Upvote 2
Link to comment

Hi,

I had an event publish this morning.  I happen to add a photo page this evening and when verifying it, I saw the new date/time at the top of the listing.  It had the right date, but the time as defaulted to 00:00 - 13:00 .   Glad I noticed the new fields when I edited it again, so was easy to correct.  And no, the event was not from midnight to 1PM.

 

Good feature, but you might want to take a look a any caches that published in today.

 

Cheers,

-TG

  • Upvote 1
Link to comment

Why are the only options for time on the quarter hour (:00 :15 :30 :45)?  Occasionally events have 'odd' times to start/end - such as on March 14, 2015 when some were at 3/14/15 at 9:26 (PI to 7 places).

 

And the default time of 0:00 - 13:00 is for any event created before this was added (my Jan 27 event showed that when I edited it just now).  And be careful when scolling the page with the mouse wheel, if the cursor is in/on one of the time boxes the time will scroll at high speed.

 

ETA:  Thank you for adding this.  Not being able to see the event date on our GPSr's has been a minor irritant.

Edited by The Jester
  • Upvote 2
Link to comment
4 hours ago, Geocaching HQ said:

events can only happen on one day

 

Hmm, this is new.

 

How can I do a three-day camping event?  Three separate events?  Or is that event stacking and thus disallowed?

 

EDIT: Ah, I think I know the answer.  Continue to nominate one day as the "official" date, and continue to accept attended logs for the day(s) before and after.

 

ED-EDIT: That Keystone, he's fast.  We've got a camping-event guideline?  I'll be darned, we do.

 

Edited by Viajero Perdido
  • Upvote 1
Link to comment

This is awesome!

 

I love that the minimum time and no multi-day events finally get enforced! We see a lot of events published with wrong times, and even no times at all. And many work very hard to hide the event times, for some reason I can't understand. So this is a huge improvement to the entire community!

 

A few requests from me:

  1. Please allow custom times, like 11:11
  2. Please add option for time format to the user preference page, I don't want times to show in 12-hour format
  3. The automatically added date-time text in the description looks ugly in my otherwise nice description, does it have to be there? :)
  • Upvote 4
Link to comment
1 hour ago, thomfre said:

The automatically added date-time text in the description looks ugly in my otherwise nice description, does it have to be there? :)

Agreed.

The length of "created by" name can vary significantly, so designing variable placement in the header should keep that in mind.  It seems to make sense to have the CO's name and contact method together in one line, then have the Event Date/Times together in another line.

 

I would like to see something like one of the following:

image.png.420a3482bd2468e04941f5727855bcc7.png

  • Upvote 2
Link to comment

I noticed a new issue now. Some events will have two times, and it's hard to tell which one's correct. One time added by the new field (the CO might not have seen it while editing) and the old written by the CO.

 

This could be because the CO didn't notice, and a default/random time was selected in the new fields. Or it could be that the CO changed the value in the new field, without updating the existing information in the description.

  • Upvote 1
Link to comment
14 minutes ago, thomfre said:

Or it could be that the CO changed the value in the new field, without updating the existing information in the description.

 

Oh that could be a big issue of confusion. The time portion of listings isn't realy prominent when viewing a listing with a description containing (typically) so many more important detalis. I'd think it's quite likely that the listing time be get a set-and-forget while changes to an event get made in the listing description.

It may be up to community to notice if there's a disconnect and inform the CO that one of the times stated is wrong (description or time fields)

Link to comment
13 hours ago, firennice said:

Can it be changed so that when I export from the cache page with "Add to Calendar" it will export the times as well?  I use google, not sure if that makes a difference. 

 

The "Add to Calendar" functionality has not been updated in this release, meaning that it still adds an event for the entire day. We are considering updates for this feature in future releases, as well as updates to the Dashboard's event widget. Additionally, our localization team is looking into the best way to offer time formats that would serve our global community.

 

4 hours ago, thomfre said:

I noticed a new issue now. Some events will have two times, and it's hard to tell which one's correct.

 

A time is only added to an event cache when a new cache is created or an existing event cache is edited, so it's very likely that the CO is editing the cache and not noticing the new time requirement. We'll try to let COs know when we see this occur, though hopefully it will be a small number of caches that have this inconsistency.

Link to comment
44 minutes ago, hleeful said:

A time is only added to an event cache when a new cache is created or an existing event cache is edited, so it's very likely that the CO is editing the cache and not noticing the new time requirement. We'll try to let COs know when we see this occur, though hopefully it will be a small number of caches that have this inconsistency.

Maybe the best is to not have any default value in the time fields? So that the CO must explicitly set a time for it to do anything. That would probably be the best in the long run anyway, to avoid default values being submitted and published.

  • Upvote 5
  • Love 1
Link to comment
18 hours ago, Geocaching HQ said:

Cache owners can now input their event times during the Cache Submission Process (CSP) and update them on the edit page. Players can see the event times at the top of the Event Cache page on Geocaching.com, as well as in the description.

2 hours ago, hleeful said:

A time is only added to an event cache when a new cache is created or an existing event cache is edited, so it's very likely that the CO is editing the cache and not noticing the new time requirement.

 

When I read the OP, I thought the time fields were an optional item.  I think it was the use of "can" rather than "must" in the first line that made me think it was optional.  But in a later post, you're saying that it's a "requirement".  As much as I don't like picking on individual words, I'm a bit confused.  Could you clarify whether populating the time fields is now mandatory or optional?

 

 

2 hours ago, hleeful said:

The "Add to Calendar" functionality has not been updated in this release, meaning that it still adds an event for the entire day. We are considering updates for this feature in future releases, as well as updates to the Dashboard's event widget.

Looking forward to seeing the times in the event widget.  Thanks.

 

 

  • Upvote 1
Link to comment

BUG:  On an event page, the time and date (in the current fixed format) is added under the heading Geocache Description.

 

This suggests it's part of the description.  It isn't.  It's part of the metadata.

This suggests the CO wrote that text.  They didn't, and may have wished to use a different time/date format suitable for the region, and may feel embarrassed to have a pessimal format pretending to be part of their own text.

 

Metadata should be outside the CO's invisible box.  No?

 

EDIT: I see something about "interim measure".  Why not wait until you get the whole package together, whatever that might entail?  Ideally, that'd include actual times going into the calendar link, which'd seem to be the best use of this new rigidity.

 

Edited by Viajero Perdido
  • Helpful 1
  • Love 1
Link to comment
9 minutes ago, Viajero Perdido said:

This suggests it's part of the description.  It isn't.  It's part of the metadata.

Actually that data is sorted into the now abandoned "Short Description" field which is reused for this purpose.

Link to comment
1 hour ago, HHL said:
2 hours ago, Viajero Perdido said:

This suggests it's part of the description.  It isn't.  It's part of the metadata.

Actually that data is sorted into the now abandoned "Short Description" field which is reused for this purpose.

This feature allows for the event time information to appear in GPX files downloaded to a handheld GPS.  The brand new fields at the top of the page would not appear on a geocacher's handheld GPS, which could be frustrating if the event times are not repeated in the long description by the Event Host.

  • Upvote 1
  • Helpful 1
Link to comment
7 hours ago, HHL said:

Actually that data is sorted into the now abandoned "Short Description" field which is reused for this purpose.

 

Since the Description panel in the new search/map thing doesn't include the Short Description field, the time information doesn't appear anywhere when using that. Below are screen shots from the full cache page and the description panel of the new search. Oh what a tangled web...

 

CachePage.png.6de4c2c595eb35bc25b000de3f382409.pngSearchDescription.png.79b4862e3e25face771ae2bf5b6a0149.png

Link to comment
29 minutes ago, thomfre said:

If times like these aren't allowed anymore, the reviewers would need to start enforcing it as well: http://gc.link/GC81R2M

Not seeing your point here.  The event cuts across the midnight hour, the system cannot handle that at present, so the 11:45 pm end time is the best solution available.  Geocaching HQ has said that they're exploring solutions for late night events as a future enhancement. 

 

There was nothing here for the reviewer to "enforce."

  • Upvote 1
Link to comment

Nice feature. but....

It would have been nice if you could write custom times, not in 15 min increments. A timepicker, something like the uploaded picture would be nice.

And another ting. It should not be any default values in the form. That only leads to wrong times in the field. 

last ned.jpg

  • Upvote 1
Link to comment
4 hours ago, Olet said:

It would have been nice if you could write custom times, not in 15 min increments. A timepicker, something like the uploaded picture would be nice.

Yep. My calendar makes it very easy to 15-minute increments, which is convenient when creating most events/appointments, but it allows me to specify other times if I want.

 

4 hours ago, Olet said:

And another ting. It should not be any default values in the form. That only leads to wrong times in the field.

Absolutely. There is no "default time" for an event. Don't provide a default value for a form if there is no meaningful default.

  • Upvote 7
Link to comment
5 hours ago, niraD said:

Don't provide a default value for a form if there is no meaningful default.

Agreed. The fields should default to be blank. If they're now considered to be required fields, then a warning can be displayed indicating that the fields need to be filled out before the page can be saved. Defaults for things that don't have defaults leads to things like the plethora of 1.5/1.5 cache listings or the often-misused Owner Maintenance log type.

  • Upvote 3
  • Helpful 1
Link to comment
6 minutes ago, Viajero Perdido said:

If they default to blank, they had better make clear what format is expected. I understand it's hardwired to some other country's format...

By blank, I just mean unfilled in some way. Based on what's described here, I get the sense that the times are selected from a drop-down list. If that's the case, then the default should just be the empty-first-option that's typical of drop-downs. If the user doesn't change the drop-downs to actual times, then the form can throw up a warning in big red text telling the user that they need to do so before they can save.

 

An alternative would be to have both the start and end times default to the same time, such that attempting to save the page with the unchanged default settings would violate the event-length restriction and force the user to change them. Maybe just have them both default to 00:00?

 

Regardless of which way things go, something needs to change. Having technically-valid defaults doesn't make sense for the event time fields and will inevitably lead to issues.

  • Upvote 3
Link to comment
18 hours ago, Keystone said:

Not seeing your point here.  The event cuts across the midnight hour, the system cannot handle that at present, so the 11:45 pm end time is the best solution available.  Geocaching HQ has said that they're exploring solutions for late night events as a future enhancement. 

 

There was nothing here for the reviewer to "enforce."

Look at the description. Two different times, making it very confusing. Which one is correct?

Link to comment
20 hours ago, ivans said:

This new functionality is  really great and we appreciate it. We hope, a small fine tuning is ongoing ;-) 

Date in GPX file obtained via Download GPX link is wrong, see picture.

 

Thanks

ivans

 

This is not small fine tuning but likely to cause people to attend on the wrong day.

  • Upvote 2
Link to comment
On 1/18/2019 at 7:14 AM, thomfre said:

There are lots of events published/updated with default times and a different time in the description. Please remove the default time value.

I suggest the drop downs should be empty. If no specific times are selected then the short description should be say something like "No times selected by the organiser see main listing". 

In reality this new feature seems to be creating problems and potential confusion where none existed before.

Edited by lodgebarn
  • Upvote 3
  • Helpful 1
Link to comment
2 minutes ago, HHL said:

Could you please explain what you mean by this?

As more people start to edit their events, more and more events get default times added.

 

Edit: I've been manually adding times to events for large parts of the world for 2+ years, so it's easy for me to see how this issue is spreading.

Edited by thomfre
Link to comment
On 1/18/2019 at 2:41 PM, ivans said:

This new functionality is  really great and we appreciate it. We hope, a small fine tuning is ongoing ;-) 

Date in GPX file obtained via Download GPX link is wrong, see picture.

 

Thanks

ivans

 

If you are living in a timezone about 8 hours behind UTC, than the time might be correct since the "Z" in the time element means UTC.

Edited by WolfHH
Link to comment

As for exporting event times in the calendar, the current export is NOT an all day event. It defaults to 00:00 GMT-7 (screenshot below - I'm GMT-4) [If updates are being made, how about putting the coordinates in the location field and moving the GC link to the description?]

1615824860_ScreenShot2019-01-22at22_48_56.png.c46b51c0ffcd9cf495681eff9372c540.png

 

It would seem to me that exporting to calendar shouldn't be a problem. The location of the event is already known, as is its time zone. Plenty of sites have no problem exporting calendars and respecting the time zone of the location.

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

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.

  • Upvote 2
Link to comment
On 1/17/2019 at 3:09 PM, stebu said:

NaN Invalid Date NaN, 18:00 - 18:30

 

I get that too.

 

EDIT:  Fixed already.  That didn't last long.

 

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

 

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