On Wed, 20 Feb 2019 at 12:44, Colin Smale <colin.sm...@xs4all.nl> wrote:
Even in this case, we should take the trouble to define the syntax for a > duration, in such a way that the definition is reusable and extensible. > Should it be 2.5 hours, or should it be 2 hours 30 minutes? Using only > fractional hours will be problematic to encode 17 minutes, for example; and > unwieldy to encode 6 months. > You seem to be assuming, contrary to all the preceding discussions in this thread, that only one unit is allowed. All preceding discussions mentioned minutes, hours, days and months. 2.5 hours or 90 minutes. > Lets be clear, the storage format can (and should) be decoupled from the > display format. What is stored in the database can easily (assuming it is > sufficiently standardised!!!) be translated for human consumption, and the > inverse can be done when storing. It happens in just about every computer > program ever. Storing the value as an ISO string assures > machine-readability and editors, browsers etc can use standard libraries to > format it for humans, in whatever language you like. > You are living in an ideal world that does not exist. Go to the standard carto. Use the query tool. All the translation mechanisms you posit do not exist. If you are prepared to produce a changeset for the standard carto to do that, AND manage to get it incorporated, then you'd have a point. Well, if you could guarantee that ALL data consumers would implement it, you'd have a point. Well, provided all the editors also incorporate it. If you can achieve all of that then you have my support. Actually, you wouldn't have my support. Because if you can achieve all of that we can encode durations as seconds rather than strings that have to be parsed. Among the advantages of using the ISO standard include that all that > thinking has already been done, and the documentation of the syntax is > available freely in millions of languages. > And read by almost no data consumer. And, unlike the simpler forms of opening hours, it's less likely to be understood by a data consumer. -- Paul
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
