OSD time string in nicer formatting

[polarbear_n]

Currently the OSD can only use ${vehicle.position_time_iso8601} for displaying date and time. This is good for debugging purposes, but very long for building a little GPS clock on-screen.

It would be good to have the components such as %h %m %s available to configure a clock according to the local demands of the user.

Thanks

[mvglasow (2)]

this shouldn't be too hard, I'm thinking of something similar to what I implemented for coordinates in #549 - allowing format strings to be appended.

The format string could either be [iso8601] for ISO 8601 format (what we see now) or a commonplace date/time format string.

Examples:

• [iso8601] gives 2010-07-07T20:49:36:789Z
• [HH:mm:ss] gives 20:49:36
• [MM/dd/yyyy hh:mm:ss tt] gives 07/07/2010 8:49:36 PM

The only thing I'm not 100% sure about at this point is how periods in the format string get handled (needed for some local pre-ISO date/time formats), but that would be worth a try.

That part is routine. The challenge begins when time zones enter the field.

• Does anybody know if position_time_iso8601 returns GPS time or UTC? (The difference is currently 15 seconds and gets transmitted with the GPS signal, so UTC time can be derived from the GPS signal.)
• Then it would be a matter of converting to local time using standard C library functions; we would somehow need to pass also this information, either by extending the format string or by introducing a separate attribute (vehicle.position_time_local).
• How do we tell the timezone to use for local time? Through C library functions? To be tested, results may differ between platforms, but probably the best functionality/complexity tradeoff for now. Set in navit.xml? Would be a really cheap hack if nothing else works reliably, to be considered an emergency workaround at best. From GPS position? In my opinion the coolest way to do it, but it would depend on lots of data (timezone borders, DST start/end dates) and might lead to a "skippy" time display when used near a timezone border.

I'll try to implement something...

[polarbear_n]

Replying to http://wiki.navit-project.org/index.php/user:mvglasow:

Sounds good. If you go for the timezone issue, I think having it configurable in the XML file should be sufficient, including the value of the GPS-leap-seconds.

If you do so, please also keep the plain GPS-time as one of the options.

I would vote strongly against automatic timezone switch since that always leads to confusion, in particular if you travel across them. You would have the display the current timezone as well which takes extra GUI space again.

(In mobile phones, timezone switched by the network operator is one of the prime reasons your alarm clock function gets confused...)

[mvglasow (2)]

what I have in mind is to start with the routine part and leave out the time zone conversion; once that works as expected, I'll either introduce some modification to the format string to indicate whether to use local or GPS time, or introduce a second attribute like position_time_local which works the same way but returns local time.

I'm pretty much against storing any time zone-related information in the XML file for various reasons:

• the missing leap seconds are transmitted with the GPS signal, that is, UTC can be determined precisely without supplying any static information.
• the time zone should be set on the device somewhere (depending on the OS), so if we can use that, we should. When running Navit on a smartphone which gets confused by timezone updates from the network, Navit wouldn't be the only victim of that and the corresponding feature should be disabled on the device itself.

Thinking about it, if we derive the time zone from GPS information, this should be fed back to the OS and Navit should still rely on the timezone provided by the OS. However, given the complexity of that, this is an esoteric feature for now.

<irony> if you want a phone with no confusing time zone updates, get a Freerunner and put Android on it. Time sync there is so utterly broken that you end up setting the time manually anyway... but that's a different rant. </irony>

[mvglasow (2)]

update: work is in progress; the attribute can be specified with a format string of the form

{ iso8601 | [ local; | offset ; ] format }

where

• offset is a literal offset such as +02:00 (sign, hours, colon, minutes)
• format is a time format string which follows the syntax for the C strftime function

Examples:

[iso8601] will give the familiar ISO output [local;%Y-%m-%d %X] will give the date and time, using the local time zone of the system (tested successfully on WinCE so far) [%X] will give the time in UTC, using the local system time format [+01:00;%X] will return the time of the UTC+01:00 time zone (this would be Western European Daylight Savings Time or Central European Time)

Still working on a kink regarding explicit time offsets, then the code will need some cosmetic updates (I needed to introduce a new helper function and need to find a suitable place for it in the code).

[mvglasow (2)]

Kinks are worked out and the code works on Windows CE. Patch follows.

As always, any code I came across and understood is documented.

[mvglasow (2)]

Formatted and local time for position_time_iso8601

[mvglasow (2)]

Afterthought: this patch does not contain any compensation for GPS/UTC time differences as Navit should already be receiving UTC from the GPS devices.

gpsd definitely implements this correction of receivers that don't do it internally (though they use static values and if another leap second is introduced, we will need an update of gpsd).

NMEA-based receivers "don't need it" according to the info on the gpsd website, that seems to me that NMEA receivers already implement this correction. In fact the specs of several NMEA sentences claim the timestamps are in UTC (not in GPS time).

As for other GPS providers (Android, iPhone etc.) - I haven't looked into details but would assume a similar situation. Should any of our GPS sources not implement this correction, we would need to add that in the vehicle definition.

[mvglasow (2)]

Just need someone to merge the patch into the SVN tree...

[akashihi]

Applied in [r3543 ​http://navit.svn.sourceforge.net/viewvc/navit?view=revision&revision=3543]

[polarbear_n]

documented new features in OSD wiki page ​http://wiki.navit-project.org/index.php/OSD