Internet date

Richard Gaskin ambassador at
Tue Nov 1 18:48:44 CET 2016

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:

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:

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:

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
  Ambassador at      

More information about the use-livecode mailing list