Time formats

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark

Locked
FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Time formats

Post by FourthWorld » Wed Mar 11, 2015 12:13 am

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
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: Time formats

Post by monte » Wed Mar 11, 2015 3:53 am

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.

Here's the php date function for reference http://php.net/manual/en/function.date.php

Then it would be easy enough to put together a library that returned the appropriate string for a given spec dateFormat("ISO8601") etc...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

malte
Posts: 1098
Joined: Thu Feb 23, 2006 8:34 pm
Location: Ostenfeld germany
Contact:

Re: Time formats

Post by malte » Wed Mar 11, 2015 8:49 am

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...

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: Time formats

Post by LCMark » Wed Mar 11, 2015 9:08 am

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 :)

SparkOut
Posts: 2839
Joined: Sun Sep 23, 2007 4:58 pm

Re: Time formats

Post by SparkOut » Wed Mar 11, 2015 9:14 pm

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.

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Time formats

Post by FourthWorld » Wed Mar 11, 2015 9:31 pm

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.
Stylistic preference noted. Going forward I'll use fewer colloquialisms when writing in the Engine Contributors section.
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 :)
The two on my mind at the moment are the two I mentioned above, the format used in RSS and the one used in Apache's Common Log Format.

RSS uses RFC822:
http://www.faqs.org/rfcs/rfc822.html

CLF uses %d/%b/%Y:%H:%M:%S %z
http://en.wikipedia.org/wiki/Common_Log_Format
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: Time formats

Post by LCMark » Thu Mar 12, 2015 9:11 am

Stylistic preference noted. Going forward I'll use fewer colloquialisms when writing in the Engine Contributors section.
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.

Locked

Return to “Engine Contributors”