Problem with converting time

Richard Gaskin ambassador at
Fri Mar 17 12:44:06 EDT 2017

Michael Doub wrote:

 > time = 1489755600
 > Mac:      dateitems = 2017,3,17,9,0,0,6
 > server:   dateitems = 2017,3,17,12,0,0,6
 > Code:   get time
 > convertit to dateitems
 > Richard here is another example:
 > time = 1489752000
 > mac:    dateitems = 2017,3,17,8,0,0,6
 > server: dateitems = 2017,3,17,12,0,0,6
 > I just wanted to double check that I was showing you good comparison
 > since I am copying from multiple windows of debug output.
 > I don't understand how the local time comes into play when converting
 > a constant number of seconds.  The resulting date should be a
 > constant as well.
 > What am I missing?

The beauty of "the seconds" is that the value you get is in GMT, 
regardless of where the machine is at the moment that value of obtained. 
  It does the offset according to the locale settings on the local machine.

"The seconds" and "the internet date" are the only two forms that take 
local time zone settings into account.

The benefit with this approach is that either can be used in 
applications where usage may span time zones but you need to maintain 
time stamps that will work across any time zones.

For example, suppose I'm in Los Angeles and I share a server app with 
one user in New York, another in Brisbane, and another in Edinburgh.

GMT offsets for each are:

Edinburgh: 0
New York: -4h
Los Angeles: -7h
Brisbane: +10h (they're across the International Dateline)

The "internet date" format reflects this explicitly, noting the GMT 
offset at the end of the string it returns:

   Fri, 17 Mar 2017 09:09:03 -0700

But "the seconds" of course is just an integer, so while the GMT offset 
has also been accounted for it's less evident.

If all four of us get "the seconds" at the same moment, the value we get 
will be the same, in GMT time.

But since only one of us is actually in the GMT time zone, how does it 
know?  That's where the local system settings come into play.

When *obtaining* either "the seconds" or "the internet date", local time 
zone is used to create a value that can be understood globally.

When *converting* either "the seconds" or "the internet date", LC uses 
time conversion routines dependent on the system locale settings of the 
machine where the conversion is taking place.

With "the internet date" the time zone is explicitly included, so it 
adjusts from that GMT offset to bring it into alignment with the GMT 
offset in the local OS.

With "the seconds", the value is already adjusted to be GMT, so 
conversion adjusts it again for the local settings to deliver an 
accurate representation of that moment in local time.

In the example above, all four users would get the same value from 
querying "the seconds" at the same moment, no matter where they are in 
the world.

And when my software needs to display the date and/or time in 
human-readable form, the "convert" command takes local settings into 
account to deliver an accurate representation that makes sense in local 

So if I modify a record right now, in my system it'll show March 17 at 
9:18 AM.  But when my Brisbane use sees the modification date that I've 
stored using "the seconds", he'll see March 18 at 2:18 AM, which is the 
same global moment.

In short:

The key to getting accurate reflections of time is to store either "the 
seconds" or "the internet date" on the server (or really, anywhere 
timestamps may be shared across time zones), and then do any conversions 
needed for human readability locally.

If you do a conversion from either of those two formats on the server to 
any other format, the result will be correct for the server's locale, 
but unless you're nearby probably not correct for you.

Quick Exercise:

It took me a while (and some experimentation) to appreciate that "the 
seconds" reflects GMT just as "the internet date" does, something I 
learned from Sarah Reichelt back in the day.

One quick way to verify this is to check while changing your local 
machine's Date and Time settings:

Set to Los Angeles: 1489768020
5 seconds later,
Set to Montreal:    1489768025
10 seconds after that,
Set to London:      1489768035

Except for the few seconds it took me to click on my Locale map in my 
Control Panel, the numbers are effectively all the same.

Once I became confident with that, I've used it for everything on 
servers ever since (except logging - I like the built-in readability of 
"internet date" in logs).

  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