#672 Publish timezone as a global

[Matthew Hauer]

The timezone is currently stored as a static member in timestamp.c, leaving it unreachable to the bulk of the GridLAB-D system. This information is useful for various clock operations, and could be published as a global string.

[David P. Chassin]

• owner changed from dchassin to mhauer
• priority changed from undetermined to minor
• status changed from new to assigned
• milestone changed from Unscheduled to Version 3.0 RC 1

Timezone can be as much SSSS-##.##DDDD, which means we'll have to use char32.

Also, are we going to publish the spec or the timezone. The spec can be either a timezone or a country/region/city (locale) definition. I would support publishing "timezone" which is the actual resolved default timezone (e.g., PST+8PDT) and "timelocale" separately using something like char256. Another option is to separate the time locale into "timecountry" "timeregion" and "timecity", which may be useful for various purposes. Doesn't seem necessary with variable expansion working now, but might make life simpler.

[Jason Fuller]

• owner changed from mhauer to jcfuller

[David P. Chassin]

Recommend we not do this before review of 4.0 design because the intention was always to allow multiple timezones in a single model. This would make such an enhancement at even more difficult.

[Jason Fuller]

Agreed. I think we want to expose this information, but I don't think we want a GLOBAL TZ. That said, I don't think we have a way of assigning objects different timezones, do we?

[David P. Chassin]

Indeed and that is the crux of the design question that should be deferred to 4.0 at the earliest.