Date() always displays UTC time

Even this command

    local d = date(time(), 'l');

will result in UTC time. Is there anyway to get the local time? I just subtract 8 hours now, but I’m not sure if that works with daylight savings… Is there some way to set the timezone?

Reza

The imp’s clock is always UTC; the code needed to deal with time-zones is a surprisingly complex and bulky, and probably not a good use of the imp’s limited resources. The server, on the other hand, could perhaps in future know what’s going on with time-zones and tell the imp what’s up. However, for the time being, the best thing to do is to use imp.configparams (as documented under imp.configure) to make a server-visible setting that tells your code what its UTC offset is. That way, at least you only have to use the planner, not edit your code, when daylight-savings starts or stops.

Peter

I don’t change the clock in my car when daylight savings kicks in, let alone go to the planner and change the code. I can probably hard-code some dates in there for daylight savings.

it would be great if we could code modules that go in the planner. or just a text dialog so i could label boxes. is that going to happen? a google voice sms module would be great.

You will be able to code server-side squirrel (the blocks are called agents) in the near future :slight_smile:

Hopefully the server-side squirrel code will have a more extensive api, and support for timezones :slight_smile:

The following Device code allows me to add one hour onto UTC for British summer time.

`// Returns 1 if the clock should show summer time.

function bst_adjust (t)
{
local march, october;
march = last_sunday_in_march(t);
october = last_sunday_in_october(t);
if ((t.yday > march)
&& (t.yday < october))
return 1;
if ((t.yday == march)
&& (t.min >= 60))
return 1;
if ((t.yday == october)
&& (t.min < 60))
return 1;
return 0;
}

function updateClock()
{
local t = date();
local hour = t.hour+bst_adjust(t);
if (hour>23) hour = 0;

// move to the first row, first column
lcd.setCursor(0, 0);
lcd.writeString(format("%02d:%02d:%02d", hour, t.min, t.sec));

// update the clock again in 1 second
imp.wakeup(1, updateClock);

}
`

What do these two functions look like:

last_sunday_in_march()
last_sunday_in_october(t)

Sorry, I forgot to include these functions.

`// Number of days from start of year to UTC/BST change day
function last_sunday_in_march(t)
{
local days, sunday;
days = 89; // Days from 1st Jan to end of march, less 1 'cos we count from 0
if (t.year%4 ==0) // Add a day if this is a leap year
++days;
sunday = t.year;
sunday *= 5; // Find a position in the week for sunday
sunday /= 4;
sunday += 4;
days -= sunday%7;
return (days);
}

function last_sunday_in_october(t)
{
local days, sunday;
days = 303; // Days from 1st Jan to end of october, less 1 'cos we count from 0
if (t.year%4 ==0) // Add a day if this is a leap year
++days;
sunday = t.year;
sunday *= 5;
sunday /= 4;
sunday += 1;
days -= sunday%7;
return (days);
}`

I’m completely new to imp and squirrel, but what about this one? :slight_smile:

local UTC_HOUR_OFFSET = 2; local hour = (d.hour+UTC_HOUR_OFFSET)%24;

Obviously I’m UTC+2.

If you don’t have day light saving, then you only need to have a single offset. However if you have daylight saving you need the standard offset + the offset when daylight savings kick in.

the only way to automate it is by using an available (free) web API like googlemaps timezone.
/* TimeZone API info at : https://developers.google.com/maps/documentation/timezone/ */

Supply coordinates and get timezone offset + DST offset in return.

In case it’s an issue for you, google’s API requires https. TimeZoneDB.com is an alternative that doesn’t. Don’t know if they’ll be around as long as google, but you might find it useful.

Google’s API works like a charm with the standard Squirrel constructs available for http processing. Didn’t need to do anything special for it.
Fact is that a lot of commercial websites depend on this API so for sure will be around for a while.

Yes, I have little doubt that Google’s will be around. I was questioning the potential longevity of the alternative I mentioned. :wink: