We have established that the `datetime(now)` combo is both currently 
broken (on some systems), and has some shortcomings in its design (on 
all systems, both broken and otherwise).


I think the key issues in finding any satisfactory solution are the 
following:


- The current broken variant of the behavior has been around for quite a 
while, and people have been using it. From their perspective, the only 
thing wrong about the broken behavior is that there's a trailing "Z" 
behind the default date/time strings generated.

- Probably the most common use case for the `datetime(now)` combo would 
ideally have it report local time (matching the broken behavior), rather 
than UTC as originally intended and documented.

- Aside from this combo, the use cases for the `now` pseudo-variable may 
actually give more weight for UTC-based behavior.

- It would be excessively complex to make the `now` pseudo-variable 
convey timezone information to `datetime` (especially considering that 
one might want to do arithmetics on it first, or store it in another 
variable, or any other scenario where it would have to have numeric 
value semantics).

- We can't have both at the same time.


I hereby present the following alternative approaches as possible solutions:


(A) Timezone Global Setting
---------------------------

- A `timezone` global setting is added, with possible values being 
either `local` or `utc`.

- In `local` mode, `now` returns a local time based value on all 
systems, and the `datetime` format string defaults to `%Y-%m-%d 
%H:%M:%S` (note the absence of any time zone specifier whatsoever; see 
notes below for reasons).

- In `utc` mode, `now` returns a UTC based value on all systems, and the 
`datetime` format string defaults to `%Y-%m-%d %H:%M:%SZ` (as it 
currently does; note the presence of a literal "Z" time zone specifier 
to explicitly indicate UTC).

- For now, choosing `timezone local` will prompt a warning that the 
behavior with respect to daylight savings time needs further testing, 
may be subject to change, and is to be regarded as experimental.

- If `timezone` is not explicitly specified, it will default to `utc` 
(being the originally intended and documented behavior), with the first 
use of `now` or `datetime` prompting a warning that the behavior may not 
be as expected.

- In deviation of the above, if `#version 3.7` is specified, and in the 
absence of an explicit `timezone` setting, the behavior of `now` and 
`datetime` will match the current behavior (i.e. `now` will exhibit 
`utc` or `local` mode behavior depending on platform, while `datetime` 
will invariably exhibit `utc` mode behavior), and the warning will be 
somewhat different, in that it will indicate that the behavior is 
specifically for backward compatibility and may lead to bogus results on 
some systems and/or unexpected results on others.

- Switching between modes will be supported, but since values obtained 
from `now` in one mode would lead to bogus results when used in 
`datetime` (with default format string) in the other mode, a warning 
will be issued if there is any switch between a use of `now` and a 
subsequent use of `datetime` without an explicit format string.


NOTES:

- The most common `local` mode use cases presumably don't need an 
explicit time zone specifier, so including a trailing "%z" or "%Z" in 
the default format string would only unnecessarily add another instance 
of time zone handling that could turn out to have pitfalls of its own. 
Users who need such information are still free to include such suffixes 
by specifying a custom format string.

PROS:

- The default `datetime` format string is automatically adapted to 
whatever mode the user chooses.

CONS:

- It might turn out that `local` mode can't be made to work properly due 
to issues related to daylight savings time.

VARIANTS:

(A.1) Alternatively, `now` could be implemented to always return UTC 
based values, with `datetime` instead automatically adding a timezone 
offset when in `local` mode. This variant should be safe from potential 
daylight saving times issues, and the mode could be switched at will 
without exercising any extra caution. However, it would also mean the 
user couldn't easily probe for the time zone offset.


(B) Timezone Pseudo-Variable
----------------------------

- A `timezone` pseudo-variable is added, evaluating to the timezone 
offset to UTC in fractions of a day.

- `now` will be fixed to return a UTC based value on all systems (unless 
`#version 3.7` is specified, in which case behavior will be as currently 
implemented, while prompting a warning if the result differs from fixed 
behavior),

- `datetime` will continue to work as currently implemented, i.e. using 
a string that implies an UTC-based timestamp. A warning might be issued 
if no explicit format string specified and the timestamp parameter is 
anything other than pure `now`.

- Local date/time strings can thus be generated using 
`datetime(now+timezone,FORMAT)`


PROS:

- No switching between modes needed.
- The solution should be immune to daylight savings time issues.

CONS:

- The value of the timezone variable would have unexpected units (days 
instead of hours).
- Getting local date/time strings would always require am explicit 
format string.

VARIANTS:

(B.1) Have `datetime` default to specifying no timezone information 
whatsoever. This variant would avoid the need to specify an explicit 
format string to produce proper local date/time strings. However, it 
would produce misleading results for `datetime(now)` as the absence of a 
timezone specifier would erroneously imply local time when it would 
actually be UTC.

(B.2) Have `now` return local time instead of UTC, and use 
`now-timezone` to get UTC. This variant would avoid the need to specify 
an explicit format string to produce proper local date/time strings, 
while still getting sane (albeit local time) results from 
`datetime(now)`. However, this approach might turn out to not work 
properly due to potential daylight savings time issues.


(C) Datetime mode parameter
---------------------------

This approach is somewhat similar to (A.1):

- `now` will be fixed to return a UTC based value on all systems (unless 
`#version 3.7` is specified, in which case behavior will be as currently 
implemented, while prompting a warning if the result differs from fixed 
behavior),

- An optional timezone mode parameter is added to `datetime`, with 
possible values being either `local` or `utc`, the default being `utc`.

- In `local` mode, `datetime` automatically adds a timezone offset to 
the timestamp parameter (which is always presumed to be based on UTC), 
and the format string defaults to `%Y-%m-%d %H:%M:%S` (note the absence 
of any time zone specifier whatsoever).

- In `utc` mode, `datetime` takes the timestamp parameter as-is, and the 
format string defaults to `%Y-%m-%d %H:%M:%SZ` (as it currently does; 
note the presence of a "Z" time zone specifier to explicitly indicate UTC).


PROS:

- The default `datetime` format string is automatically adapted to 
whatever mode the user chooses.
- The solution should be immune to daylight savings time issues.

CONS:

- The presumably more frequent use case, `local` mode, would always 
require to specify the mode parameter.

VARIANTS:

(C.1) The default of the mode parameter could be specified to be `local` 
rather than `utc`. This would avoid the need to explicitly specify the 
parameter in the presumably more common `local` use case. However, for 
backward compatibility it would require that `datetime` behave 
differently when `#version 3.7` is specified, and would still require 
specifying the mode parameter each time `utc` mode is desired.

(C.2) This approach could be combined with (A.1), using the global 
setting as the default when `datetime` is used without an explicit mode 
parameter. This would avoid the need to explicitly specify the parameter 
each time `local` mode is desired, while at the same also avoiding the 
need to make `datetime` behavior subject to `#version` setting.

Post a reply to this message