|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: clipka
Subject: Re: `datetime(now)` issue - suggestions for a solution
Date: 8 Aug 2021 19:12:51
Message: <611064f3$1@news.povray.org>
|
|
|
| |
| |
|
|
Am 09.08.2021 um 00:54 schrieb clipka:
> I hereby present the following alternative approaches as possible
> solutions:
My personal preferences lean heavily towards (A), with a perspective to
change over to (A.1) later if daylight savings time does indeed turn out
to be a problem.
(A) explicitly includes provisions to let people know that the `local`
mode may still be subject to change, for this exact reason.
The reason for any DST issues would be that, in order for stuff to work
nicely, the time zone of the timestamp "zero point" (2000-1-1 00:00)
probably needs to match the time zone applicable for (a) the point in
time represented by the timestamp, or (b) the point in time at which the
scene is parsed (and I'm not sure which of the two). Either way, since
2000-1-1 is outside the DST period for most time zones, there is reason
to expect things to break down when invoking `datetime(now)` during the
DST period, since the DST time zone typically doesn't match the regular
time zone.
Since UTC does not have a DST variant, this is a non-issue if our
numeric timestamps are always UTC-based.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
clipka <ano### [at] anonymousorg> wrote:
> 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:
> ...
could make a "fine" setting for 'povray.conf', eg:
[timezone]
; local
utc
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
From: clipka
Subject: Re: `datetime(now)` issue - suggestions for a solution
Date: 9 Aug 2021 05:20:18
Message: <6110f352@news.povray.org>
|
|
|
| |
| |
|
|
Am 09.08.2021 um 09:07 schrieb jr:
> hi,
>
> clipka <ano### [at] anonymousorg> wrote:
>> 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:
>> ...
>
> could make a "fine" setting for 'povray.conf', eg:
>
> [timezone]
> ; local
> utc
I disagree.
`povray.conf` is there to tie the *NIX front-end(!) of your POV-Ray
installation in to your *NIX run-time environment, and nothing more.
Mainly to let the binary know where to find its auxiliary files
(includes, primarily), and what directories never to access even if a
scene says pretty please with a cherry on top.
There's also no such file in POV-Ray for Windows; such information is
handled entirely differently there.
Also, it is definitely a setting that individual scenes should be able
to override. Because in the end it will usually be the scene author who
knows best whether they want some date or time displayed in their scene
in local or UTC format - and it might change from scene to scene, or
even between different portions of the scene.
If anything, one could argue that there should be an INI setting to
specify the default, which in turn would make it configurable globally
via the master `povray.ini`.
But the more places we want to add to tweak the setting, the more work
it is to implement, and for the time being I'd like to keep it simple,
and leave the implementation of such an INI default as an exercise to
the reader, so to speak.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
clipka <ano### [at] anonymousorg> wrote:
> Am 09.08.2021 um 09:07 schrieb jr:
> > hi,
> >
> > clipka <ano### [at] anonymousorg> wrote:
> >> 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:
> >> ...
> >
> > could make a "fine" setting for 'povray.conf', eg:
> >
> > [timezone]
> > ; local
> > utc
>
> I disagree.
I do too, now. :-)
> `povray.conf` is there to tie the *NIX front-end(!) of your POV-Ray
> installation in to your *NIX run-time environment, and nothing more.
> Mainly to let the binary know where to find its auxiliary files
> (includes, primarily), and what directories never to access even if a
> scene says pretty please with a cherry on top.
a better suggestion would have been:
[locale]
tz = {local|utc}
lang = en_GB.utf8
as you say, conf provides environment type info. given that 'strftime()' uses
locale, a setting to provide a preference/default could be useful. (POV-Ray
appears to use the locale already, anyway)
> There's also no such file in POV-Ray for Windows; such information is
> handled entirely differently there.
ok, did not know that.
> Also, it is definitely a setting that individual scenes should be able
> to override. ...
sure, thought setting a convenient default, and override in 'datetime()'s second
arg, if required.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> - 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.
Why not keep it the way it is an have an option/flag for removing the Z?
Gotta head out in a few, so only briefly:
A lot of this seems complicated, and I personally dislike too many options and
settings.
Would it be a bad thing to have localtime (), utctime (), and timezone () as
completely separate functions? No idea what to do about daylight savings time
since it's such a bad idea that there are people organizing and petitioning to
get rid of it all together.
Post a reply to this message
|
|
| |
| |
|
|
From: clipka
Subject: Re: `datetime(now)` issue - suggestions for a solution
Date: 9 Aug 2021 07:33:01
Message: <6111126d$1@news.povray.org>
|
|
|
| |
| |
|
|
Am 09.08.2021 um 12:53 schrieb jr:
> a better suggestion would have been:
>
> [locale]
> tz = {local|utc}
> lang = en_GB.utf8
>
> as you say, conf provides environment type info. given that 'strftime()' uses
> locale, a setting to provide a preference/default could be useful. (POV-Ray
> appears to use the locale already, anyway)
No, that's not really it.
You don't need to tell POV-Ray whether your system HAS a time zone or
not. Because your system DOES, period. Even if that timezone happens to
be UTC.
In the context of the issue, you have to tell POV-Ray whether you want
to operate in the context of that time zone, or rather prefer to operate
in a context that is universal across time zones.
And that doesn't differ based on what system you're running POV-Ray on.
It differs based on what you want to do with POV-Ray.
As for specifying _details_ about the locale, such as the actual time
zone, language or whatnot, that isn't much of a thing either. Your
system has a default locale, and there's a standard interface for making
use of that. And there's little to no point in using a different one for
POV-Ray (except possibly on a per-scene basis, but in that case
`povray.conf` wouldn't be the right place anyway).
>> Also, it is definitely a setting that individual scenes should be able
>> to override. ...
>
> sure, thought setting a convenient default, and override in 'datetime()'s second
> arg, if required.
As I said, the INI file mechanism would be the way to go for such purposes.
Post a reply to this message
|
|
| |
| |
|
|
From: clipka
Subject: Re: `datetime(now)` issue - suggestions for a solution
Date: 9 Aug 2021 07:56:38
Message: <611117f6$1@news.povray.org>
|
|
|
| |
| |
|
|
Am 09.08.2021 um 13:17 schrieb Bald Eagle:
>> - 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.
>
> Why not keep it the way it is an have an option/flag for removing the Z?
Because the current status is inconsistent. It currently does different
things on different systems.
Just adding a flag to suppress the trailing "Z" seems a bit daft to me,
as it just dumps all the responsibility into the user's lap to get
things working properly, when we could just as well implement a
mechanism that does everything right out of the box, while not being any
more complex - from the user's point of view.
> Gotta head out in a few, so only briefly:
> A lot of this seems complicated, and I personally dislike too many options and
> settings.
Maybe you're confuzzled by the fact that I've described impementation
details, not just what the user sees in a standard use case.
> Would it be a bad thing to have localtime (), utctime (), and timezone () as
> completely separate functions?
If you can describe a system of such functions that works consistently,
and is reasonably foolproof to use, then I'd be happy to take it into
consideration.
As it currently stands, this sounds like a system with a couple of
building blocks but no mortar to properly tie them together, so the user
has to mix their own and hope that it's suited for the task.
Pitfalls are plenty in the world of time and timezones, so I'd prefer
users not have to worry about it themselves (unless they know what they
are doing and consciously decide to do their own worrying).
> No idea what to do about daylight savings time
> since it's such a bad idea that there are people organizing and petitioning to
> get rid of it all together.
For the time being (no pun intended), daylight savings time does exist
as an undeniable fact of life we have to put up with. If we try to
ignore it, we will produce a program that breaks at least half of the
time in half of the world.
Post a reply to this message
|
|
| |
| |
|
|
From: clipka
Subject: Re: `datetime(now)` issue - suggestions for a solution
Date: 9 Aug 2021 08:02:52
Message: <6111196c$1@news.povray.org>
|
|
|
| |
| |
|
|
Am 09.08.2021 um 13:56 schrieb clipka:
>> Would it be a bad thing to have localtime (), utctime (), and timezone
>> () as
>> completely separate functions?
>
> If you can describe a system of such functions that works consistently,
> and is reasonably foolproof to use, then I'd be happy to take it into
> consideration.
(Also, remember that `now` and `datetime` already exist, and we should
make at least some good faith effort to make them consistent - both with
respect to themselves, as well as each other, and any additional time
related stuff we may want to add - and rid them from any undesired
quirks if possible.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
clipka <ano### [at] anonymousorg> wrote:
> Am 09.08.2021 um 12:53 schrieb jr:
>
> > a better suggestion would have been:
> >
> > [locale]
> > tz = {local|utc}
> > lang = en_GB.utf8
> >
> > as you say, conf provides environment type info. given that 'strftime()' uses
> > locale, a setting to provide a preference/default could be useful. (POV-Ray
> > appears to use the locale already, anyway)
>
> No, that's not really it.
>
> You don't need to tell POV-Ray whether your system HAS a time zone or
> not. Because your system DOES, period. Even if that timezone happens to
> be UTC.
:-) ("divided by a common language")
> In the context of the issue, you have to tell POV-Ray whether you want
> to operate in the context of that time zone, or rather prefer to operate
> in a context that is universal across time zones.
exactly. hence tell POV-Ray, in .conf ideally, what the system/user preference
is, ie whether 'now' ought to mean "local" or "utc", unless overridden.
> ...
> As I said, the INI file mechanism would be the way to go for such purposes.
perhaps.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|