 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2021-08-11 7:08 AM (-4), clipka wrote:
>
> 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.
These are my results at 8:59 p.m. local time:
Version datetime(now) Time Zone Boost
------- ------------- --------- -----
3.7.0 (1) 2021-08-13 00:59:36Z GMT 1.53
3.8.0-alpha.9893777 (1) 2021-08-13 00:59:36Z GMT 1.66
3.8.0-alpha.9945627 (1) 2021-08-13 00:59:37Z GMT 1.66
3.8.0-alpha.10013324 (1) 2021-08-13 00:59:38Z GMT 1.66
3.8.0-alpha.10064268 (2) 2021-08-12 20:59:39Z local/std 1.66
3.8.0-beta1 (1) 2021-08-13 00:59:40Z GMT 1.66
3.8.0-beta2 (3) 2021-08-13 00:59:41Z GMT 1.66
My OS is openSUSE Leap 15.0 (GNU/Linux). However, the latest version of
openSUSE is Leap 15.3, and I wouldn't know if the behavior is the same.
I also suspect that I do not have the latest version of Boost, but my
computer is actively thwarting my every attempt to upgrade the OS, and
is now without access to any active repositories.
> 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?
My locale does not observe DST.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
