Jump to content

LOL - Geocaching.com does not know 2010 exists

mtbikeroz

By mtbikeroz
in Website

Followers 2

Recommended Posts

mtbikeroz

+mtbikeroz

Posted
  • Author
Posted

 

It is still 2009 at frog central.

 

Ah, but the system allows us to log in real time in OZ all other days of the year. eg, I can log at 1am on a day, the log date accepts the current Australian time and day, and in the state listings records it as "logged -1 days ago". (Until Frog central catches up, whereby it changes to "logged today")

 

So why is 1/1/YYYY any different. All I can say is LOL, funny!

Link to comment
Chrysalides

+Chrysalides

Posted
Posted

I went to log a cache, here in AUSTRALIA, at 7:15am, 1 January 2010, and the Geocaching.com drop down list in the dates for logging finds DOES NOT HAVE 2010 - LOL

Serves you right for rushing into the new year ahead of almost everyone else! :)

 

I'm sure it can be fixed with a GreaseMonkey script (sorry, it just had to be said :) )

Link to comment
4wheelin_fool

4wheelin_fool

Posted
Posted (edited)

This is definitely a bug and one that we will make a point of correcting before this time next year; for now, however, the system goes off Seattle time and will not show 2010 in the various date drop-downs for another 10 hours. Sorry about that; all I can say is we are working on it! :P

 

What he means is that it will be fixed, er working in 10 hours. :rolleyes:

Edited by 4wheelin_fool
Link to comment
7rxc

7rxc

Posted
Posted

This is definitely a bug and one that we will make a point of correcting before this time next year; for now, however, the system goes off Seattle time and will not show 2010 in the various date drop-downs for another 10 hours. Sorry about that; all I can say is we are working on it! :P

 

What he means is that it will be fixed, er working in 10 hours. :rolleyes:

 

Question should be WHICH ten hours?? Their choice?

 

Why not do the usual thing... system in UTC and the user selects their OWN time zone... so their own displays are always correct... that could be in the cookies or registration data...

 

Doug

Link to comment
Chrysalides

+Chrysalides

Posted
Posted
I cannot imagine a bug that would be of lower priority.

Until Dec 31 2010 rolls around. It is not mission critical, but it is visible and slightly embarrassing - and more so when it comes around the second time.

 

As for what bug is of lower priority, I think I know as much about Groundspeak's bug prioritization as you do (which is, in my case, next to nothing).

Link to comment
sbell111

+sbell111

Posted
Posted (edited)
I cannot imagine a bug that would be of lower priority.

Until Dec 31 2010 rolls around. It is not mission critical, but it is visible and slightly embarrassing - and more so when it comes around the second time.

1) I'm pretty sure that this was the second time. 2) I don't see why anyone would be 'embarrassed' by this issue.
As for what bug is of lower priority, I think I know as much about Groundspeak's bug prioritization as you do (which is, in my case, next to nothing).
This is true. However, I think that it's reasonable to assume that resolving issues such as this are prioritized. Given that this particualr 'bug' only affects a handful of cachers for a few hours each year, I suspect that it would not be deemed mission critical. Edited by sbell111
Link to comment
Chrysalides

+Chrysalides

Posted
Posted
1) I'm pretty sure that this was the second time. 2) I don't see why anyone would be 'embarrassed' by this issue.

Seems to be a new bug though, from Moun10Bike's response. I suppose a different incarnation of the bug (same symptom, different cause) could exist before. I certainly haven't been around long enough to know.

 

As for embarrassing, if a bug is highly visible, and with one whole year to do something about it, I didn't fix it, I would feel embarrassed. I'd like to believe the coders take some pride in their work as well. Of course, the potential for embarrassment doesn't mean it will get fixed. I've chosen embarrassment over fixing a bug often enough.

However, I think that it's reasonable to assume that resolving issues such as this are prioritized. Given that this particualr 'bug' only affects a handful of cachers for a few hours each year, I suspect that it would not be deemed mission critical.

Maybe. Another reasonable assumption is that the bug is actually pretty easy to fix, and since it is visible to most geocachers (including most of the United States), would get priority.

Link to comment
Lil Devil

+Lil Devil

Posted
Posted
... since it is visible to most geocachers (including most of the United States), would get priority.

Wrong. It wouldn't be visible to anyone in the United States, unless perhaps you live on the East Coast and you went caching after midnight, and you try to log your finds before 3am. After 3am, the problem goes away. Those on the West Coast will never see the problem.

 

On the other hand, those in Australia will see it a lot. They can go caching in the morning, go home to log their find, and the new year won't show up on the drop-down menu until late-afternoon their time.

 

Those in Europe will only see the problem if the try to log before 9am. I'm sure few people go caching early in the morning and get home that early to log. So not many people there will see the problem.

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