Update (now archived) Oozy Rat from Geocaching.com in 2023

[GPSBabelDeveloper]

Downloaded from cache page, not a PQ.

[codacy-production[bot]]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
-0.07%	100.00%

Coverage variation details

| | Coverable lines | Covered lines | Coverage | | ------------- | ------------- | ------------- | ------------- | | Common ancestor commit (1aa1554c03158d42346ae7adf600ede41a382a4f) | 23104 | 16005 | 69.27% | | | Head commit (88d4ef69677ce79822b404be1142083e8a175efe) | 23104 (+0) | 15989 (-16) | 69.21% (**-0.07%**) | **Coverage variation** is the difference between the coverage for the head and common ancestor commits of the pull request branch: ` - `

Diff coverage details

| | Coverable lines | Covered lines | Diff coverage | | ------------- | ------------- | ------------- | ------------- | | Pull request (#1196) | 2 | 2 | **100.00%** | **Diff coverage** is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: `/ * 100%`

See your quality gate settings    Change summary preferences

[tsteven4]

My preference is that input reference files from an external source are used exactly as produced from the source.

[robertlipe]

Oh, yes. The old "the logged time was close to midnight and my $TZ is different than the Github runner's so the date rolls over" trick.

Joy.

[tsteven4]

Possible solutions:

1. add utc option to html writer, e.g. like xcsv writer.
2. conditionally run test in fixed time zone like xcsv.test

   if command -v tzselect >/dev/null 2>&1 ; then
   export TZ='America/Denver'
   echo "  including xcsv timezone conversion test"

[tsteven4]

The good news is the date time in the gpx files is now unambiguous. If your okay using UTC dates in html and text then fine, otherwise if you want the local date I think 1. or 2. needs to be implemented.

[robertlipe]

Engineer Robert agrees. "No excuses"

PM Robert says this is a somewhat known landmine of the site. Besides, it's super obscure and nobody's noticed this in years. (The log time or even date. Is really only useful for sorting so as long as it's internally consistent, the leading need is met. In my 15000-ish finds, that number being off a few hours has never mattered to me.) I know it's like six lines of code, but I'd rather not incur command line flag inflation.

I know I've pooh poohed away the other sites, but I wonder if the DE or AUS sites record and leak time for some fields as Seattle time. There's really not a winning move for them if they're trying to be compatible with something that's broken.

If you feel strongly enough to withhold an approval, I'll sling the code for #1 in this PR.

Otherwise back to my POST/GET redirect nightmare.

On Wed, Oct 25, 2023, 6:25 PM tsteven4 @.***> wrote:

The good news is the date time in the gpx files is now unambiguous. If your okay using UTC dates in html and text then fine, otherwise if you want the local date I think 1. or 2. needs to be implemented.

— Reply to this email directly, view it on GitHub https://github.com/GPSBabel/gpsbabel/pull/1196#issuecomment-1780191634, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD345NXW6JIB5XVXUPVDYBGNYNAVCNFSM6AAAAAA6ORGFOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBQGE4TCNRTGQ . You are receiving this because you commented.Message ID: @.***>

[tsteven4]

To be pedantic I think both UTC and local time are often the wrong choice, but this is true of almost all our use of local time. I think that when we use the local time of the system processing the data we often really want the local time at the coordinates we are referring to. But, that isn't easy to come by.

Either UTC or local are fine with me for these formats, I'm not sure they are used! Fix 2. is easy to implement and works in CI, so nothing sneak by. Fix 1, especially with UTC=n, gives the user an opportunity to correct, e.g. for the processing location and data collection location being in different time zones. But I am fine with it as it is.

As an aside I'm in no mood to support things that violated the schema almost 20 years ago and have disappeared in the interim.

[robertlipe]

We agree. If you're viewing your cycling data while you're on vacation, you PROBABLY want the time to be local where they were recorded. EXIF data should probably be local to where the picture was taken. But if you're near the edge of a TZ, you don't want it flipping around mid-track. But you might be in one of the counties that doesn't observe DST. Or the tracks might have been taken before the rollover was moved. It's all very messy.

Groundspeak just made an even bigger mess by merging the date you found the thing and the time you logged finding the thing when they really have nothing to do with each other...and then screwing up the time zone on that.

I share your skepticism that these formats are used very much at all (they were handy in the PDA era before GPSes became powerful enough to read GPX natively) but the time in the logs specifically just doesn't matter.

UTC it is. Will be submitting this in a few moments.

Re: schema grief. You have demonstrated a much higher tolerance for pain on such things than I have. I know the history of this niche that led to the original fragmentation and the later industry implosion that put everyone into survival mode vs. "we'll do our own thing for ideological purity because someone may (gasp) be making money from this". I'm more than fine not giving these cases another thought until someone fusses - and maybe not even then.

I find most of the ordering requirements in GPX just weird. Maybe I'm just not familiar with readers that impose additional requirements. I mean,

at the top makes sense but I can't imagine a reader caring if HDOP and VDOP are swapped. TIL C++20 gives us https://en.cppreference.com/w/cpp/chrono/gps_clock . It doesn't really solve any problems for us, but it's now a thing. If we had std::chrono 15 years ago, that would have been one less reason for QtCore... But stdc++ still doesn't have a decent string class. :-/ On Wed, Oct 25, 2023 at 7:44 PM tsteven4 ***@***.***> wrote: > To be pedantic I think both UTC and local time are often the wrong choice, > but this is true of almost all our use of local time. I think that when we > use the local time of the system processing the data we often really want > the local time at the coordinates we are referring to. But, that isn't easy > to come by. > > Either UTC or local are fine with me for these formats, I'm not sure they > are used! Fix 2. is easy to implement and works in CI, so nothing sneak by. > Fix 1, especially with UTC=n, gives the user an opportunity to correct, > e.g. for the processing location and data collection location being in > different time zones. But I am fine with it as it is. > > As an aside I'm in no mood to support things that violated the schema > almost 20 years ago and have disappeared in the interim. > > — > Reply to this email directly, view it on GitHub > , > or unsubscribe > > . > You are receiving this because you commented.Message ID: > ***@***.***> >