Problem with converting time

[Michael Doub]

Sorry guys, I must not have been clear in my statement of the problem.  
Here is the code:

put 1489755600 into tVar
convert tVar into dateitems
  -- on the mac tVar contains 2017,3,17,9,0,0,6
  -- on the server tVar contains 2017,3,17,12,0,0,6

The local time should not be involved since you are converting a fixed 
value.  What is happening?

-= Mike


On 3/17/17 12:44 PM, Richard Gaskin via use-livecode wrote:
> 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 time.
>
> 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).
>