Default Timezone and daylight time hardcoded

[wilberforce]

In the xsHost files the timezone and daylight time are hard coded:

static int32_t gTimeZoneOffset = -8 * 60 * 60;		// Menlo Park
static int16_t gDaylightSavings = 60 * 60;			// summer time

https://github.com/Moddable-OpenSource/moddable/blob/public/xs/platforms/esp/xsHost.c#L471-L472

These could be set up as a#define so they can be overridden in the build.

However, it might be more flexible if it was in the config section of the manifest.

We currently have:

"config": {
		"sntp": "pool.ntp.org",
	}

and this is picked up by "setup/network": "$(BUILD)/devices/esp/setup/network",

https://github.com/Moddable-OpenSource/moddable/blob/public/build/devices/esp/setup/network.js#L44

So perhaps the timezone details should be set here from the config?

[phoddie]

Not everyone lives in California? ;)

Using the JavaScript config approach can set the timezone yourself that way now:

import Time from "time";
import config from "mc/config";

Time.timezone = config.timezone;

It would be convenient if that was automatic. There's no setup for manifest_base.json at the moment. That's easy to add. But, I hesitate to add it, only because it is something that would be present everywhere - taking a little more time and space. In that respect, the define mechanism has an advantage as it is literally no additional code -- only a different initialization value for the timezone global value.

[wilberforce]

Not everyone lives in California? ;)

I was going to say something in the initial post but held back!

What tripped me up was not the Timezone I had set that to -12 for NZ, however the time was out and hour - that's when I discovered the daylight offset, and the default is 3600 which might trip up other people!

And when daylight time is over for you will you change it in GitHub :-;

The trouble with the Config.json is that everything is a string - so you can't put "-8 * 60 * 60" without adding an evaluate.

[phoddie]

The trouble with the Config.json is that everything is a string - so you can't put "-8 * 60 * 60" without adding an evaluate.

The config values from the command line are strings. The config values in a manifest file may be any valid JSON value. Here's a couple from the SDK that contain numbers, one that is an entire object:

"config": {
	"screen": "ili9341",
	"touch": "",
	"rotation": 180,
},

"config": {
	"WM8978": {"address": 26, "sda": 19, "scl": 18, "hz": 100000},
},

That said, I think the defines approach is reasonable to start. A real product isn't going to use any configuration option, but will have some kind of preference so the time zone and daylight offset can be change after the product leaves the factory.

[wilberforce]

Yes - that's the next step. It would be great to have defaults come from config.json and if these could get merged with the preferences object - perhaps interating throught the domains?

[wilberforce]

Here's a couple from the SDK that contain numbers

I think I edited the post after as the * got stripped - I don't think you can have:
"timezone" : -12 * 3600 ?

[phoddie]

It would be great to have defaults come from config.json and if these could get merged with the preferences object - perhaps interating throught the domains?

I think the way that time zone is managed is outside the domain of Moddable SDK. There are lots of ways it could be done, so no matter what we do in the SDK it not be what most want. Having a reasonable default (for people who live outside California..) does make sense for the SDK. Let's start there.

I think I edited the post after as the * got stripped - I don't think you can have:
"timezone" : -12 * 3600 ?

That's true. You can't have expressions in JSON. But you can have

"timezone": -43200

which isn't pretty but it works.

[wilberforce]

Currently I'm using this as hour offsets, as It's more legiable:

		"timezone": {
			"offset": -12,
			"dst": 0,
		},

I'm leaning towards using the posix style:
"EST+5EDT,M3.2.0/2,M11.1.0/2"

This means that the user would not need to adjust for daylight time, however the parsing is complicated and the user interface would be tricky too.

[phoddie]

The legibility is nice on your "timezone" approach.

On ESP32, the Posix approach can work as the libc there already has parsers for that. But, as a general solution for microcontrollers, it seems heavier than needed. The right solution really depends on the needs of the product you are building.