Am 11.08.2021 um 13:08 schrieb clipka:

> These variants were used in the following POV-Ray versions:
> 
> v3.7.0.0 - v3.8.0-alpha.10013324 (2019-01-14):
> Variant (1)
> 
> v3.8.0-alpha.10064268 (2019-02-19) - v3.8.0-alpha.11272893 (last alpha):
> Variant (2)
> 
> v3.8.0-beta.1:
> Variant (1) again
> 
> v3.8.0-beta.2:
> Variant (3)

For the records, the v3.8.0-x.freetype versions (which seem to have 
gained more popularity than I'd have expected) should be using the 
following source code variants:

v3.8.0-x.freetype.1 - v3.8.0-x.freetype.2:
Variant (1)

v3.8.0-x.freetype.3 - v3.8.0-x.freetype.4:
Variant (2)

Post a reply to this message

datetime(now)
2021-08-12 00:14:08Z

$ date
Thu 12 Aug 2021 12:14:26 NZST

My time zone is New Zealand, Standard Time (it's winter here)

Persistence of Vision(tm) Ray Tracer Version 3.8.0-beta.1.unofficial (g++ 9 @
x86_64-pc-linux-gnu)

  Boost 1.71, http://www.boost.org/

$ uname -a
Linux Pavilion 5.8.0-59-generic #66~20.04.1-Ubuntu SMP Thu Jun 17 11:14:10 UTC
2021 x86_64 x86_64 x86_64 GNU/Linux

Cheers
Ton

Post a reply to this message

Hi clipka,

Here is what I get:

```
#version 3.8;
#warning concat("\ndatetime(now) is ", datetime(now), "\n")
```
gives:
```
Persistence of Vision(tm) Ray Tracer Version 3.8.0-beta.1.unofficial (g++ 7 @
 x86_64-pc-linux-gnu)
....
File 'test.pov' line 2: Parse Warning:  datetime(now) is 2021-08-12 05:20:38Z
```

`date` gives `2021/8/12 thursday 14:20:38 JST` (I am in Japan, output edited to
remove the japanese characters, and there is no DST here)

Hope it will help,
Pascal



clipka <ano### [at] anonymousorg> wrote:
> Folks,
>
> regarding the `datetime(now)` issue, I need more information from you
> folks, to make sure I'm not hunting a phantom.
>
>
> As far as I can tell, there may be as many as three variants of behavior
> out there, with `datetime(now)` returning the current time as either...:
>
> (A) UTC time,
>
> (B) LOCAL time, properly respecting daylight savings time, or
>
> (C) LOCAL time, IGNORING daylight savings time,
>
> with all variants appending a literal "Z" (intended to indicate UTC, but
> being bonkers in cases (B) and (C)).
>
>
> There are also two variants of the source code out there... well,
> actually three by now:
>
> (1) Some old boost-based source code;
>
> (2) some newer C++11-based code; and
>
> (3) a variant of (1) with a fix to enforce behavior (A).
>
>
> These variants were used in the following POV-Ray versions:
>
> v3.7.0.0 - v3.8.0-alpha.10013324 (2019-01-14):
> Variant (1)
>
> v3.8.0-alpha.10064268 (2019-02-19) - v3.8.0-alpha.11272893 (last alpha):
> Variant (2)
>
> v3.8.0-beta.1:
> Variant (1) again
>
> v3.8.0-beta.2:
> Variant (3)
>
>
> I need your help to test the different variants of the code (especially
> (1) and (2)) on your machines, and let me know:
>
> - What behavior you are observing for code variant (1);
> - what behavior you are observing for code variant (2);
> - what operating system you are using; and
> - what version of boost POV-Ray has been compiled with.
>
> Bonus questions:
>
> - Using genuine POV-Ray, have you ever, and beyond doubt, observed
> behavior (B) during times when DST was in effect in your time zone?
>
>
> (Please disregard derivatives such as rpov in this test/poll. They have
> no impact whatsoever on the question I'm eager to get answers to.)
>
>
> I have a hunch that I may have been looking in a completely wrong
> direction in this matter.

Post a reply to this message

Op 11/08/2021 om 16:18 schreef clipka:
> Am 11.08.2021 um 14:13 schrieb Thomas de Groot:
>> I don't know if the following is answering your questions but anyway, 
>> these are the versions I have currently accessible on my laptop:
> 
> Information about your actual time zone would have been helpful, but I 
> have enough material to make an educated guess about that.
> 
Sorry for that; I always get confused when timezones are involved ;-). 
Seems I am at UTC+2 at the moment.

>> The third one is deviant. No idea about "boost version".
> 
> When you start up POV-Ray for Windows, the initial message pane content 
> will list the boost version close to the bottm. But with the Windows 
> versions being distributed as binaries I can reconstruct that piece of 
> information myself, so no worries there.

Well, learned something new today it seems. :-)
[never too old, never too old...]

-- 
Thomas

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 11.08.2021 um 18:17 schrieb jr:
>
> >> Information about what time zone you've set up on your system would also
> >> be of interest (at least if it's very close to UTC; if it's far off,
> >> "not even close to UTC" is all I'd need to know).
> >
> > v close, GMT.  currently on "British Summer Time" (Wed 11 Aug 17:15:45 BST
> > 2021).
>
> Thanks, that's an important piece of the puzzle. If I'm not having a
> total brain fart, this means that (A) and (C) are indistinguishable on
> your system.

UTC + "British" time are the same from October to March.  not sure about
"indistinguishable", utilities like 'date' always use/display a time zone.


regards, jr.

Post a reply to this message

Am 12.08.2021 um 08:43 schrieb jr:

>> Thanks, that's an important piece of the puzzle. If I'm not having a
>> total brain fart, this means that (A) and (C) are indistinguishable on
>> your system.
> 
> UTC + "British" time are the same from October to March.  not sure about
> "indistinguishable", utilities like 'date' always use/display a time zone.

What I mean is this: Would you have any way of telling whether _POV-Ray_ 
is displaying local non-DST, or whether it is instead displaying UTC?

Even if it _did_ append time zone information, you still couldn't tell 
whether the two pieces of information would actually be related. For all 
you know, POV-Ray could take UTC and independently append a string that 
happens to represent your proper time zone - or it could take non-DST 
local time and append a string that happens to look like a UTC time zone 
identifier (which is literally what happens in scenario (C)).

Or it _could_ take UTC and append a string that happens to look like a 
UTC time zone identifier (which is literally what happens in scenario (A)).

The thing is, with time zone set to UTC+0 when DST is not in effect, you 
just can't tell.

Post a reply to this message

"Ton" <ton### [at] gmailcom> wrote:
> datetime(now)
> 2021-08-12 00:14:08Z
>
> $ date
> Thu 12 Aug 2021 12:14:26 NZST
>
> My time zone is New Zealand, Standard Time (it's winter here)
>
> Persistence of Vision(tm) Ray Tracer Version 3.8.0-beta.1.unofficial (g++ 9 @
> x86_64-pc-linux-gnu)
>
>   Boost 1.71, http://www.boost.org/
>
> $ uname -a
> Linux Pavilion 5.8.0-59-generic #66~20.04.1-Ubuntu SMP Thu Jun 17 11:14:10 UTC
> 2021 x86_64 x86_64 x86_64 GNU/Linux
>
> Cheers
> Ton

With beta 2 I have the same issue, datetime is 12 hours behind.
date = 2021-08-12 07:03:48Z

$ date
Thu 12 Aug 2021 19:03:48 NZST

Persistence of Vision(tm) Ray Tracer Version 3.8.0-beta.2.unofficial (g++ 9 @
x86_64-pc-linux-gnu)

Cheers
Ton

Post a reply to this message

Am 12.08.2021 um 09:11 schrieb Ton:

> With beta 2 I have the same issue, datetime is 12 hours behind.
> date = 2021-08-12 07:03:48Z

Technically that's not an issue at all: The trailing "Z" is the official 
ISO timezone code for UTC. And that's exactly how `datetime` is intended 
and documented to work.

We're already working on a solution though to get proper local time to 
you people (with correct DST and all the bells & whistles) as an 
alternative.

Post a reply to this message

Am 11.08.2021 um 13:08 schrieb clipka:

> regarding the `datetime(now)` issue, I need more information from you 
> folks, to make sure I'm not hunting a phantom.

The data I've gotten so far supports my suspicion, so I'd like to take 
this call to arms into a different mode of operation.

Anyone who hasn't replied so far, but wants to assist in this, I'd just 
like you to confirm that the following holds for your system, too:

--
When using either POV-Ray v3.7 or v3.8.0-beta.1 (sic! I don't care about 
beta.2 in this context), `datetime(now)` returns a string that matches 
the current time as UTC (frequently referred to as "GMT", and being 
equal to London local time when DST is not in effect), with a trailing 
literal "Z" (which "happens" to be the ISO timezone code for UTC).

(please specify operating system, POV-Ray version and timezone when 
replying.)
--

Unless someone reports otherwise, my preliminary verdict is as follows:

- There never was a bug in the first place (well, not this one anyway) 
that would show on some _systems_ and not on others. Instead, there was 
a bug that would show on some _versions_ of POV-Ray and not on others.

- `datetime()` and `now` had always been working exactly as intended and 
documented, starting with its introduction in v3.7.0.0, until...

- it was actually borked by me in v3.8.0-alpha.10064268 when I rewrote 
the code to use C++11 features instead of boost, to no longer require 
the boost datetime library.

- The new code would instead have `now` report time since 2000-01-01 
00:00 local time, instead of UTC, while `datetime` would continue to 
expect UTC and thus printed a wrong time (and still explicitly claiming 
it to be UTC). That time would happen to match local time, but only when 
DST was not in effect (in the northern hemisphere; in the southern 
hemisphere, the behavior regarding DST would presumably be the other way 
round).

- With the rollback to earlier v3.8.0 code, we also switched back to the 
properly working `now` code, so the bug was already absent again in 
v3.8.0-beta.1; and my attempt to fix it in v3.8.0-beta.2 presumably did 
nothing at all, except waste time (both mine in developing it and yours 
in rendering scenes making use of `now`, which take a tiny bit longer to 
parse with the "fix").


Crucially, this means that the borked behavior hasn't been around very 
long (comparatively), so there isn't really much pressure to do anything 
at all in the name of backward compatibility.

It also means that I can be reasonably sure that a solution which works 
on my Windows machine will also work on your Lunix machines.


What's still left for me to do is:

* Investigate that other (probably entirely unrelated) problem regarding 
DST when using a non-default format string in `datetime`, specifically 
when using `%z` or `%Z` to display local timezone information.

* For convenience, provide a means for users to actually get a local 
date out of `datetime` (and one that respects DST, for that matter).

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> ...
> The thing is, with time zone set to UTC+0 when DST is not in effect, you
> just can't tell.

well,the system knows.  and also a good reason, imo, to have a (run time)
configuration option to tell POV-Ray.

re WFP's 'datetime(now,"%c")', I agree and see a trailing space char, as if the
'Z' had simply been overwritten.


regards,jr.

Post a reply to this message