Revisiting time zone testing

I know there is an older thread out there, but...

I have a Glance app (Zulu Time) that shows different bits of normally useless information dealing with time.  One of the bits of info displayed is the difference between local time and Zulu time (GMT).  I've been traveling around the US and it has been working as advertised.  However, I recently went through St John's Newfoundland Canada which is a half hour off.  It showed a 2 hour difference instead of 2.5.  The code is pretty straight forward, I just divide the timeZoneOffset() by 3600 and display.  I was using a Venu 2 Plus.

Here's the kicker.  When I tried to reproduce the results at home on the simulator, I could not get the time zone to change.  On my Mac Air I changed (and verified the computer agreed) the current time and ran the simulator.  The Glance showed by home time zone difference.  I even tried changing the watches location in the simulator (yes, I know it's not supposed to change anything in this cae).  Am I missing something basic?

  

Thanks

  • divide by 3600.0 instead of 3600

  • A) Too easy of a solution :D Thanks!

    B) How can I test it if the app isn't recognizing the new time on my computer?

  • I'm not sure I understand your question. Do you mean that when you set your computer's timezone to Newfoundland's TZ and start the simulator then it doesn't show the half an hour difference? Does the computer correctly display the time?

    What happens when you change the timezone to any other TZ?

    Maybe you can try to see other timezones, I know there are a few with x:30 and I think there's even one with x:15 or x:45 offset

  • I finally figured it out.  In order for my computer to allow me to test in a different time zone on my Mac, I:

    1) Turned off both "Set time and date automatically" and "Set time zone automatically using your current location"

    2) Typed in a city in the "Closest City" block

    This would then allow the app to test in the new time zone.  Simply, manually entering a time in the "Date and time" did not work.

  • Of course, because that only sets the time but keeps your actual TZ.

    But how is the float solution (/3600.0)? Does it really work?

  • Sort of.  It gave the decimal answer so I had to go in and format the results.  It gave me the float answer of -2.5000000 ish which I made a more presentable -2:30. 

    Thank you for your help.

  • If you want to present time or duration then you won't find it in the SDK, you'll need to do it yourself. This is what I use:

    function formatTime(timeInSeconds as Number, includeSeconds as Boolean) as String {
        var SIXTY = 60;
        var DIGIT1 = "%u";
        var DIGIT2 = "%.2u";
        var SEP = ":";
        var EMPTY = "";
        var sign;
        var time;
        if (timeInSeconds < 0) {
            time = -timeInSeconds;
            sign = '-';
        } else {
            time = timeInSeconds;
            sign = EMPTY;
        }
        var seconds = time % SIXTY;
        time = time / SIXTY;
        var minutes = time % SIXTY;
        var hours = time / SIXTY;
        time = sign + (hours > 0 ? hours.format(DIGIT1) + SEP : EMPTY) + minutes.format(hours > 0 ? DIGIT2 : DIGIT1)
            + (includeSeconds ? SEP + seconds.format(DIGIT2) : EMPTY);
        return time;
    }
    

  • If you want to present time or duration then you won't find it in the SDK, you'll need to do it yourself.

    A bit tangential to this thread, but there's at least one exception to this. If you return a Time.Duration from the compute() method of a simple data field, it will indeed be formatted as mm:ss by the firmware. This can be useful if you're starved for memory (e.g. you're building for very old devices.)

    This is one of those cases where the framework can do stuff that isn't exposed to the developer but I wish it was (calling Duration.toString() doesn't produce the same result :/).

    Another example is converting JSON to a Monkey C object and vice-versa.