#612 closed enhancement/feature request (fixed)
OSD time string in nicer formatting
Reported by: | polarbear_n | Owned by: | Singesang |
---|---|---|---|
Priority: | major | Milestone: | version 0.2.0 |
Component: | osd/core | Version: | git master |
Severity: | Keywords: | ||
Cc: |
Description
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
Attachments (1)
Change History (12)
comment:1 Changed 13 years ago by mvglasow (2)
comment:2 follow-up: ↓ 3 Changed 13 years ago by mvglasow (2)
- Owner changed from Singesang to mvglasow (2)
- Status changed from new to assigned
comment:3 in reply to: ↑ 2 Changed 13 years ago by 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...)
comment:4 Changed 13 years ago by 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>
comment:5 Changed 13 years ago by 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).
comment:6 Changed 13 years ago by 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.
comment:7 Changed 13 years ago by 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.
comment:8 Changed 13 years ago by mvglasow (2)
- Owner changed from mvglasow (2) to Singesang
- Status changed from assigned to new
comment:9 Changed 13 years ago by mvglasow (2)
Just need someone to merge the patch into the SVN tree...
comment:10 Changed 12 years ago by akashihi
- Resolution set to fixed
- Status changed from new to closed
Applied in [r3543 http://navit.svn.sourceforge.net/viewvc/navit?view=revision&revision=3543]
comment:11 Changed 12 years ago by polarbear_n
documented new features in OSD wiki page http://wiki.navit-project.org/index.php/OSD
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:
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.
I'll try to implement something...