In almost all cases, a datetime without timezone suffix is considered as a local time, but formatting unzoned datetime (e.g. '2017-01-02T03:04:05') with %s format returns the epoch time assuming the source datetime as a UTC time. As far as I know, this is the only exception and therefore it sometimes could cause confusion. e.g. DateFormatter behaves oddly with seconds
In order to prevent such a confusion, I think it would be better to simplify and clarify the related specifications. e.g.
- An unzoned datetime (except the number of seconds formatted by %s) should always be considered as a local time which is determined depending on the system environment.
- The number of seconds formatted by %s indicates always the elapsed seconds from the epoch (1970-01-01 00:00:00 UTC), and it cannot have any timezone suffix.
- When the user needs to process a zoned datetime (including UTC), they must add an appropriate timezone suffix explicitly to the datetime representation.
So, assuming the current timezone is UTC+09:00 - Tokyo, Japan,
- '2017-01-02T03:04:05+00:00' should be converted to '1483326245' with %s format.
- '2017-01-02T03:04:05' should always be considered as '2017-01-02T03:04:05+09:00' unless the system timezone changed, and both should be converted to '1483293845' (= 1483326245 sec. - 9 hr. x 3600 sec.) with %s format.
- Epoch time '0' should be parsed to '1970-01-01T00:00:00+00:00' (having timezone suffix) by default, but it might be useful if the @DateTimeParse() function could have another option to parse epoch time (and any datetime representation having timezone suffix) to local time. i.e. epoch time: '0' -> '1970-01-01T09:00:00+09:00' optionally [Edited]
- Epoch time '0-01:00' cannot be parsed anyway, and the parsing function should return <null>.
