Every time I turn around I find another time format I need to deal with, and inevitably it isn't supported in the engine.

So it occurs to me it might be nice to have some means of defining time formats, and/or extending the ones we have.

Would it make sense to be able to use them by their spec number? E.g., "ISO8601" could be a new time format, and "RFC2822" could be a synonym for what we currently call "internet date".

While it would be cool to have at least the dozen or so most popular formats in the engine addressable with such constants, I have to wonder if maybe a better solution would take this further, providing us some means of defining a date format.

We currently have a read-only date format. Should that also be writable?

What might we do to take the tedium out of dealing with the many different time formats we find in web logs, RSS feeds, and so many other systems in which the authors decided what the world needed most was yet another time format?

Richard Gaskin
Community volunteer LiveCode Community LiaisonLiveCode development, training, and consulting services: Fourth World Systems:http://FourthWorld.comLiveCode User Group on Facebook :http://FaceBook.com/groups/LiveCodeUsers/

Most languages have a means to define a date format for parsing or display. @FourthWorld I agree that we should allow `format` in the convert syntax to be either one of the existing formats or some date formatting string.

While I have stuff like this in libDate, I completely agree that this would be very useful. The engine implementation will always be faster than any scripted version. It would also be useful if convert would not choke on dates < 1/1/1970 and > 2036 I think it was...

I don't think that anyone would disagree about the date/time handling in LiveCode needing to be updated.

I do think that the majority of formats you encounter in IT systems are probably covered by 'the internet date' and 'the standard date' (I don't really see the utility in using ISO8601 or RFC2822 to identify them - unless one just wants to try and sound clever, arcane and require people to have to google those terms when reading your code... 'internet' and 'standard' indicate well enough what they mean, and a reference in the docs would be more than sufficient as far as I can see). (Indeed a lot of the variance you see in renderings of date/time are probably down to variations allowed in ISO8601).

I'm all for allowing choice so a customizable date format would seem to be a good option to add. I'd perhaps suggest that http://userguide.icu-project.org/formatparse/datetime is a more appropriate reference for a formatting string as it is a little more complete in terms of i18n. Also, we do need to look into taking into account non-Gregorian calendars if we are to have exemplary i18n credentials. (The current dateFormat is irksome - it probably falls under the remit of something we want to change as an 'anomaly').

By the way, whilst "Every time I turn around I find another time format I need to deal with, and inevitably it isn't supported in the engine." might be an amusing way to open a feature request, I do wonder if it is a bit of an exaggeration. If we want to make sure we have good date/time handling then having a list of as many things as possible that we are trying to model is an absolute requirement. So, @FourthWorld, please put your money where your mouth is and enumerate all these time/date formats you claim you keep encountering so we can do a proper analysis of the requirements

Much more important than the format itself to me (although desirable) is the ability to handle dates prior to 1970. I haven't yet come across a date of birth ahead of the current year so I can leave panic about 2036 for a while. There must be other use cases though. Still, date handling for a basic use is impossible with the current native implementation.

runrevmark wrote:By the way, whilst "Every time I turn around I find another time format I need to deal with, and inevitably it isn't supported in the engine." might be an amusing way to open a feature request, I do wonder if it is a bit of an exaggeration.

Haha - apologies - I did take that slightly the wrong way... Although my intent was honorable - my previous poking around into the work of time/date did indicate that most formats which are in use do come down to "ISO8601" (and variants thereof) and "RFC2822". With others being covered by, as you suggest, a customizable date format. Thus, I wanted to make sure there wasn't a whole few families out there I was not aware of, and thus would need to be taken into consideration when cleaning up / exposing the custom date format.

We'd very much like to extend the range of dates in the engine - but at the moment we use platform APIs to do the core processing which means we are restricted to the date ranges they provide. Generally, date/time processing isn't all that hard... However, the critical piece (which we rely on the OSes for) is the translation between universal and local time - this is actually a bit of headache due to 'daylight savings time'. DST varies from timezone to timezone considerably and requires a fair bit of data to do the calculations correctly. I'll put it on the list to re-review whether we can move the OS APIs we are using forward to allow a greater range of dates without us having to implement the functionality and include the data ourselves.