JohnBrinkman
commented
7 months ago I'll defer to the working group to make this decision. It would be helpful to look at the use-cases more closely. If the context is PDF/Forms.Next, then there are extensions that provide extensive timezone support.
As it currently stands, date/time representation is in UTC. while all date/time parts arguments (with the exception of
toDate) and return values from date/time query functions (likehour), are interpreted as from a local time zone.While this is a convenient default arrangement, I could imagine cases, where you would want to make your expression agnostic to the time zone settings on the machine they will be running, or if you just want to always work with "UTC".
As a side-note, one of such cases is getting simpler tests for date/time query functions :)
My suggestion would be, that we add an optional string
tzparameter to all relevant functions, which represent an ID from IANA time zone database. Default value will be an empty string (convenientlynullcoerces to that), which signifies using the local time zone. Invalid values would throw an error. Would assume an evaluation error instead of a type error, astzdbis continuously updated.Additionally, it might be convenient to allow setting the default time zone in the interpreter settings, as in some environment (like Node.js), you cannot change the default time zone multiple times at runtime. Though I don't think this is relevant to the specification in general.
The functions in question are:
datetimedayeomonthhourminutemonthtimetoDate(to specify the fallback time zone)todayweekdayyearI don't think, that there are time zone offsets more granular than minutes (at least I hope so...), so there is no need for
tzinsecondandmillisecond.This would be an extension to what OpenFormula had for the functions, but my assumption is, that Excel sheets don't "travel" between time zones that often or you work mostly with just dates, so it is not a common problem to have, while PDF documents and software does it more frequently.