Sannyasin Brahmanathaswami wrote:
>> Is the internet date in a consistent format in every country? That
>> is, except for the spelling of the day and month names, is the format
>> always the same?
>
> I believe the whole rest of the IT world solved this a long time
> ago.. and I've had an enhancement request in for literally a
> decade…. to have the engine date function auto output the standard
> date format in the form of
>
> YYYY-MM-DD HH:MM:SEC TZ # where TZ is picked form the local system
>
> I'm off line at the moment so I don't have the RFC number for that
> standard.
Ah, but there are so many "standards". LC's internet date uses RFC
2822, and I'd wager there are at least two dozen different time/date
formats suggested across the countless RFCs out there (the one used in
RSS is my least favorite).
Unfortunately most of them predate this XKCD comic, so we were unable to
shame them into adopting a single standard while there might have been
an opportunity to do so:
https://xkcd.com/927/
So today what we need isn't just the internet date's RFC 2822, or the
one you're proposing, but a more general framework for supporting most
(ideally all) of them.
> Yes, I know Richard will respond "The beauty of LC is you can get
> this out yourself" (hehe)
On the contrary, I've started a thread on this subject in the forums
last year - this post from Mark Waddingham is particularly helpful in
terms of understanding what's needed and how to achieve it:
http://forums.livecode.com/viewtopic.php?f=66&t=23547#p122030
The meat of it is:
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.
Kay turned me onto this fine video which goes into some of these
challenges in more detail:
https://www.youtube.com/watch?v=-5wpm-gesOY
So yes, supporting more formats is highly desirable. And since we often
need to convert entire lists of time/date info from seconds into
something human-readable, it would be best if done in the engine.
But it's just not a trivial thing to do.
> And ideally "the monthnames" and "the weekdaynames" would be
> localized automatically by the engine if there was a "my language is"
> option in the LC preferences.
The preference is expressible through the useSystemDate property.
This is more useful than a more general setting because it gives us as
developers the option of working with time and dates in a consistent
format when that's what we need, and also displaying the results of our
program's work in a localized format when that's what we need.
Having a property to govern this leaves us in control of when
consistency is more important than end-user display. A program will
often do many things with dates (such as comparing them, sorting, etc.),
and only at the end of our program does it display the result to the
user. IMO the decision to favor consistency by default is more useful
for a programming language.
Besides, IDE preferences only affect the IDE, so they wouldn't help us
when we ship our apps made with it. In fact, it could easily become an
anti-feature by giving the false appearance that dates are always
localized by default, when we'll later discover that's now how the
engine works.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
