Make date and time format independent from language setting
In Progress
Right now, at least LM 3, displays dates in a format which is depending on the language setting of Locus. Compare my images which are shot using language settings English and German.
I would like to have a constant date & time format (e.g. 2022-08-24, 17:28h) all across Locus - independent from any language setting. Right now if using English language I sometimes confusing day and month because of the US-formated date.
I like this idea 
Hello Sonny,
how do you imagine this should work? The app should offer a text field where you may define a custom date/time format?
Because otherwise, there is an almost unlimited number of possible combinations.
In the current solution, the app really picks the optimal format for the currently selected localization.
---
A little later: indeed, I've noticed a huge inconsistency in the formatting of dates over the whole app. I used at least three various methods on various places I made over the years. Good point > thanks a lot. So at least, start with the unification to identical format in all places.
Hello Sonny,
how do you imagine this should work? The app should offer a text field where you may define a custom date/time format?
Because otherwise, there is an almost unlimited number of possible combinations.
In the current solution, the app really picks the optimal format for the currently selected localization.
---
A little later: indeed, I've noticed a huge inconsistency in the formatting of dates over the whole app. I used at least three various methods on various places I made over the years. Good point > thanks a lot. So at least, start with the unification to identical format in all places.
Either you leave date/time unchangeable in Locus. But if so, please use always the same format - undepended of the language setting and take the international most common one: https://en.wikipedia.org/wiki/ISO_8601
Or you let the users select one of a handfull of predefined common date formats of a list, like it is in the preferences here: https://www.geocaching.com/account/settings/preferences
Either you leave date/time unchangeable in Locus. But if so, please use always the same format - undepended of the language setting and take the international most common one: https://en.wikipedia.org/wiki/ISO_8601
Or you let the users select one of a handfull of predefined common date formats of a list, like it is in the preferences here: https://www.geocaching.com/account/settings/preferences
I fully agree with the proposal to use the internationally standardized date-time-notation based on ISO8601. Consequent ordering from large to small units as well as dashes (-) as date delimiters and colons (:) as time delimiters make it unambiguous. You may also consider to apply this note about "Date and time in the internet" for displaying text (adressed to be read by humans) in wikipedia:
https://en.m.wikipedia.org/wiki/ISO_8601#cite_note-37
saying:
"5.6. ... NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character."
Examples then preferably should look like this (for a machine-readable time instant):
2023-08-20T18:39:57+02:00
equivalent to UTC time
2023-08-20T16:39:57Z
or (in separate date and time groups for human readers expecting local time):
2023-08-20 18:39:57
I fully agree with the proposal to use the internationally standardized date-time-notation based on ISO8601. Consequent ordering from large to small units as well as dashes (-) as date delimiters and colons (:) as time delimiters make it unambiguous. You may also consider to apply this note about "Date and time in the internet" for displaying text (adressed to be read by humans) in wikipedia:
https://en.m.wikipedia.org/wiki/ISO_8601#cite_note-37
saying:
"5.6. ... NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character."
Examples then preferably should look like this (for a machine-readable time instant):
2023-08-20T18:39:57+02:00
equivalent to UTC time
2023-08-20T16:39:57Z
or (in separate date and time groups for human readers expecting local time):
2023-08-20 18:39:57
Normally the format "05.04.2023" is standard for us. But in the title it makes sense to use "2023-04-05 10:12". By this format I have when sorting by name, automatically still a sorting by date with the same names.
In the marked field in the image is too little space for the long format.
Therefore it makes sense to use 2 formats.
Normally the format "05.04.2023" is standard for us. But in the title it makes sense to use "2023-04-05 10:12". By this format I have when sorting by name, automatically still a sorting by date with the same names.
In the marked field in the image is too little space for the long format.
Therefore it makes sense to use 2 formats.
The only format you should adjust is the one in the 2 images. Here the format "05.08.2023, 14:44" would fit better.
The only format you should adjust is the one in the 2 images. Here the format "05.08.2023, 14:44" would fit better.
Or a user defined string(s) for full timestamp, just date & just time. Would default to ISO8601. For example ref. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toISOString, such as full timestamp = YYYY-MM-DDTHH:mm:ss.sssZ, US date = MM/DD/YY etc. I like some variation of YYYY-MM-DD because tracks exported as file names sort alphabetically.
Or a user defined string(s) for full timestamp, just date & just time. Would default to ISO8601. For example ref. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toISOString, such as full timestamp = YYYY-MM-DDTHH:mm:ss.sssZ, US date = MM/DD/YY etc. I like some variation of YYYY-MM-DD because tracks exported as file names sort alphabetically.
Replies have been locked on this page!