Time zone troubles

Note: In the follow-up to this entry, you can read how I solved the issue, and as a consequence, the erroneous results mentioned below are no longer present!

For the few people who are using my hitchhike statistics programs, and as I don't (and cannot even) keep track who's downloaded them from my Google drive via the links on my site, I have some bad news...

In the "Magic" post I made on Couch$urfing on 1 July, I wrote that I'd had another 2,000+ km ride. That ride (obviously) spanned multiple countries (LT-PL-D-B-NL), more than one day (2019-06-30 to 2019-07-01) and, and that's what's causing the time zone troubles, two time zones, LT (EEST) and PL/D/B/NL (CEST).

When I record my rides, I make a note of the odometer reading at borders, and at midnight, and the latter is a problem, what's midnight when you hitchhike from LT into the west, or, more in general, from country A to country B where both are in different time zones.

In my case midnight is the local midnight, which, going back the the above ride, meant midnight in D, and that obviously results in a 25-hour day, as moving in westerly direction across a time zone usually gains you an hour. (Or just 15 minutes when moving from Bhutan into India or 2:30 when moving from China into Afghanistan, to name two land borders. In the Pacific ocean things get even weirder, check them out yourself on the Time Zone Map).

The result of the above, and we're now talking about trip 223, for which you can find the raw data by doing a search for "2019-06-30", is that the result in the "Period up to 24-hour" table for 2019 (as of 2019-07-05), to be found in the general summary file coming out of lift, by searching for "23:31 | 2218.1", is incorrect, the correct distance is "only" 2,215.0 km, from ride 3[.01] to ride 5[.02]!

I had observed this before, notably in trip 210 last year, where the same table tells you that the longest distance in a 24-hour period in 2018 is 1,914.3 km in an elapsed time of 23:17. Here the elapsed time is actually 24:17!

So, given that I would very much prefer to get rid of "false" positives, what am I going to do about this problem? The short answer is, "I really don't know yet".

The main problem is that I cannot just willy-nilly change, even internally to lift, the times into UTC format, because there's the tiny, well make that big, problem of odometer readings at midnight. Obviously I could subtract the distance covered in the "25th" hour of the day when moving to the west, or add the (estimated) distance to 01:00 when moving to the east, but that's very 1984-ish, and will not take into account that velocities may not have been uniform in the past.

I could of course solve the problem by strictly using UTC times, and record the odometer at every hour, and let the program translate the results into something mere mortals can make sense of, but given my propensity to occasionally fall asleep for shorter (or longer) periods during long rides, that's, unless I set my phone up to wake me up every hour, also not really a sensible option.

I'll probably figure something out. Turning the original "Period up to 24 hour" table from one where a period up to 24 hour equated to a calendar day into one that uses real (rolling) periods of 24 hours turned out to be ridiculously simple. This problem is likely to be a bit trickier, but somewhere, buried deep in some grey cells, I'm pondering upon something that might at least allow me to detect the "false" positives, after all, the very first table for every trip in the "lift.h-h" file already contains a column that records time zone information.

To be continued, someday…

Last updated on 1 April 2022 (Update round-robin back link)