Date format in realtime.txt

[HansR]

Can the format of the #Date field in realtime.txt (the first field) be changed by the user through simple configuration or by locale setting?
I mean the realtime.txt as is, not a user created one.

(Note: This is not a wish )

[mcrossley]

The order is always the same DD MM YY, but the separator is defined by the locale setting - that's from the wiki. I'll check that is still true in the code tomorrow...

[PaulMy]

@Mark
The order is always the same DD MM YY, but the separator is defined by the locale setting - that's from the wiki. I'll check that is still true in the code tomorrow...

You may already know that in the Cumulus1 install the Help file says:

Code: Select all

If the 'realtime' option is selected, Cumulus creates a file called realtime.txt at the specified interval, and if configured to do so, uploads it to your web site. The format of this file is as follows:

Example: 18/10/08 16:03:45 8.4 84 5.8 24.2 33.0 261 0.0 1.0 999.7 W 6 mph C mb mm 146.6 +0.1 85.2 588.4 11.6 20.3 57 3.6 -0.7 10.9 12:00 7.8 14:41 37.4 14:38 44.0 14:28 999.8 16:01 998.4 12:06 1.8.2 448 36.0 10.3 10.5 13 0.2 14 260 2.3 13 1 0 NNW 2040 ft 12.3 11.1 420.1 1

Field Example Description 
1 18/10/08 date (always dd/mm/yy) 
2 16:03:45 time(always hh:mm:ss) 

I'll make note on MX

Enjoy,
Paul

[HansR]

OK, so for the date it is always a slash (unless Mark comes with the locale separator option).

A similar issue for the realtime is the unit of pressure: I would expect the 'inHg' to be explicit but CMX filles it with 'in'. I assume that can be corrected as the logic does not change (the length might be become an issue for some though)?

[mcrossley]

The way it has been implemented in MX it will generate using locale dependent date separators.

And to answer your question on the other thread, the realtime.txt seems to have always used "in" for "inHg", so changing it now may be an issue given how many other bits of code and templates use the realtime.txt file as input.

[HansR]

The way it has been implemented in MX it will generate using locale dependent date separators.

OK, thnx

And to answer your question on the other thread, the realtime.txt seems to have always used "in" for "inHg", so changing it now may be an issue given how many other bits of code and templates use the realtime.txt file as input.

Using realtime.txt is mostly done - if not always - after splitting it on the spaces so that would not be an issue.
If one uses a fixed space of 2, yes that might.

But I understand you are not contemplating to change this to give it the correct string?

[mcrossley]

Amazingly "in" (and "in/hr" for rate) is used virtually everywhere, including the config files, graph data etc. I'm surprised there have not been comments before. I suppose it is used as a config entry and decoded to "real" text on use.

[HansR]

I guess there is not many people using inHg as unit.
Anyway, you can leave it as is, I did a q&d fix in the RT javascript.
We don't want to disturb tradition don't we

[mcrossley]

I guess there is not many people using inHg as unit.

Now you'll have every user in the USA jumping in!

But, yes I think that is the only country that still widely uses inHg