24 hour clock? Is it possible?

[RsH]

Currently I am getting date and time [in English] with AM and PM behind the time. I would prefer to have a 24 hour clock, showing the Zulu time as reported by the GPS. I would also love it if there were a time adjustment possible so that I could have RouteConverter show the LOCAL time that actually was in effect at the time, via some sort of box where I could put in the -4 or -5 hour adjustment I need for the Eastern time zone in North America. Of course, if I were in Newfoundland I would need to use -2.5 or -3.5 hours, but I am not <grin>... Are either possible? Is a registry setting appropriate for the first of these two [24 hour clock]? I don't know but I know that I much prefer that sort of display... and 14:05:24 instead of 2:05:24PM... and it makes my mental adjustment to local time much easier, as I simply switch from 14:05:24 to 10:05:24 instead of having to switch from PM back to AM.

[routeconverter]

Hi Bob,

I have to investigate what I can do there. I'm just relying on the Java Locale for formatting times. Easy and straightforward to implement ;-)

[routeconverter]

I would prefer to have a 24 hour clock, showing the Zulu time as reported by the GPS.

I've implemented this with the 2.1 release.

I would also love it if there were a time adjustment possible so that I could have RouteConverter show the LOCAL time that actually was in effect at the time, via some sort of box where I could put in the -4 or -5 hour adjustment I need for the Eastern time zone in North America. Of course, if I were in Newfoundland I would need to use -2.5 or -3.5 hours, but I am not <grin>... Are either possible?

I've proposed a global setting for the timezone offset in this thread.

[RsH]

"I have to investigate what I can do there. I'm just relying on the Java Locale for formatting times. Easy and straightforward to implement ;-)"

I have changed the Windows time format to show 24 hour clock but RouteConverter still shows the 12 hour clock when I open a track/route record. The locale seems to be Canada but how do I tell RouteConverter that I do NOT care for that 12 hour clock and want a 24 hours clock? I do not know how to edit the java locale data to convert that java code to show 24 hour time in RouteConverter or elsewhere.

[routeconverter]

The locale seems to be Canada but how do I tell RouteConverter that I do NOT care for that 12 hour clock and want a 24 hours clock?

Currently, the only way is to use Extras/Options.../Preferred language (requires restart) and then choose a European language. I guess this won't help, does it?

After some googleing I found that the date format and the 12/24 hour time is coupled to the locale.

Thus with German/French/Dutch... language (and locale) a timestamp written as 13.11.10 15:18:19, with Chinese its 10-11-13 15:18:19 while with English it is printed as 11/13/10 3:18:19 PM.

Currently I found no way to disable just the AM/PM stuff for English without affecting the other locales. I could hardwire some custom format just for English if this helps?

[RsH]

The locale seems to be Canada but how do I tell RouteConverter that I do NOT care for that 12 hour clock and want a 24 hours clock?

[quote=Currently, the only way is to use Extras/Options.../Preferred language (requires restart) and then choose a European language. I guess this won't help, does it?

Richtig... or you are right, this definitely does not help.

While I know how to do the math mentally in the PM to get back to what I really want, that 24 hour clock, it is a bit of a pain.

The time in the GPX file is already in 24 hour clock format, isn't it? If so, why does it need to be converted to 'locale' format? If used as in the input track it IS in proper format, as far as I know. [Correct me if I am wrong.]

[routeconverter]

The time in the GPX file is already in 24 hour clock format, isn't it?

Time in most parts of the world and in most software is in 24 hour clock format. SCNR ;-)

If so, why does it need to be converted to 'locale' format?

Actually it's the output that does the conversion. Internally time is stored in milliseconds since 1/1/70 and the timezone. To format it into a string, a date formatter has to be used. And by default this date formatter uses the locale to present English users their AM/PM stuff, Germans their day then month then year preference etc...

[RsH]

The time in the GPX file is already in 24 hour clock format, isn't it?

Time is most parts of the world and in most software is in 24 hour clock format. SCNR ;-)

If so, why does it need to be converted to 'locale' format?

Actually it's the output that does the conversion. Internally time is stored in milliseconds since 1/1/70 and the timezone. To format it into a string, a date formatter has to be used. And by default this date formatter uses the locale to present English users their AM/PM stuff, Germans their day then month then year preference etc...

I hope one of the following solves the problem... you have to figure it out, as I do NOT know these programming languages..
==========================================
1.

Go to http://www.epochconverter.com/epoch/batch-convert.php and on the RIGHT side of the web page pick the appropriate programming language and you will be given the conversion routine to use.

==========================================
2.

perl -e 'print scalar gmtime(hex shift), "\n"' 3BE00B2C

should give the correct result with a 24 hour clock, I think, where the "\N" or the 3BE00B2C is the UTC time. Since I do not know Perl, I am not certain of which it is. Of course, if you are not using Perl, then there has to be an equivalent somewhere.

====================================

Someone else suggested:

1 public static DateTime ConvertTime(long timeAsInteger)
2 {
3 double time = Convert.ToDouble(timeAsInteger) / 100;
4 DateTime baseDate = new DateTime(1970, 1, 1);
5 DateTime result = baseDate + TimeSpan.FromSeconds(time);
6 return result;
7 }

If 'I' pass in 117969553301 'I' get the answer 20/05/2007 21:12:13 (that's UK date format...)
Not sure whether it will help, but it's very close to 5/21/2007 00:12:13.
It's a very strange DateTime encoding though!!

============================

Another response I've discovered is:

Given that you are parsing the date from a string, the system has no way of knowing what kind of DateTime you are parsing.

DateTime has a kind property, which can have one of the three values:
* Unspecified
* Local
* Utc

So for the code you show:

DateTime convertedDate = DateTime.Parse(dateStr);

var kind = converted.Kind; // will equal DateTimeKind.Unspecified

You say you know what kind it is, so tell it.

DateTime convertedDate = DateTime.SpecifyKind(
DateTime.Parse(dateStr),
DateTimeKind.Utc);

var kind = converted.Kind; // will equal DateTimeKind.Utc

Then the system knows its in UTC time...

[routeconverter]

I hope one of the following solves the problem... you have to figure it out, as I do NOT know these programming languages..

Thank you for your help, but I guess I have to find a way around Java date formatting.

Someone else suggested:

1 public static DateTime ConvertTime(long timeAsInteger)
2 {
3 double time = Convert.ToDouble(timeAsInteger) / 100;
4 DateTime baseDate = new DateTime(1970, 1, 1);
5 DateTime result = baseDate + TimeSpan.FromSeconds(time);
6 return result;
7 }

If 'I' pass in 117969553301 'I' get the answer 20/05/2007 21:12:13 (that's UK date format...)
Not sure whether it will help, but it's very close to 5/21/2007 00:12:13.
It's a very strange DateTime encoding though!!

That looks like C# which doesn't help me since I'm using Java. It looks pretty straight forward:

private static final DateFormat TIME_FORMAT = DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.MEDIUM);
static {
TIME_FORMAT.setTimeZone(CompactCalendar.UTC);
}

and later you let the DateFormat do the formatting:

CompactCalendar time = position.getTime();
return time != null ? TIME_FORMAT.format(time.getTime()) : "";

So there are 4 options:

• choosing one date/time format for all languages (not nice)
  
• staying with the Locale specific date/time format (nice for most users)
  
• choosing a specific date/time format for English and a Locale specific for all other languages (don't know if this is what most users want)
  
• doing the date/time stuff on my own (too expensive)
  

So, I'm kind of stuck...

[RsH]

So there are 4 options:

• choosing one date/time format for all languages (not nice)
  
• staying with the Locale specific date/time format (nice for most users)
  
• choosing a specific date/time format for English and a Locale specific for all other languages (don't know if this is what most users want)
  
• doing the date/time stuff on my own (too expensive)
  

So, I'm kind of stuck...

Will this work?

import java.text.SimpleDateFormat;
import java.util.Date;

public class Main {
public static void main(String[] argv) throws Exception {

Date date = new Date();
SimpleDateFormat simpDate;

simpDate = new SimpleDateFormat("kk:mm:ss");
System.out.println(simpDate.format(date));

}
}