POV-Ray : Newsgroups : povray.beta-test : Call to Arms: Datetime Server Time
28 Mar 2024 13:41:49 EDT (-0400)
  Call to Arms: Datetime (Message 12 to 21 of 21)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Ton
Subject: Re: Call to Arms: Datetime
Date: 11 Aug 2021 20:25:00
Message: <web.61146a3421f77171152670647597fb06@news.povray.org>
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

From: BayashiPascal
Subject: Re: Call to Arms: Datetime
Date: 12 Aug 2021 01:35:00
Message: <web.6114b20621f77171a3e088d5e0f8c582@news.povray.org>
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

From: Thomas de Groot
Subject: Re: Call to Arms: Datetime
Date: 12 Aug 2021 02:17:25
Message: <6114bcf5$1@news.povray.org>
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

From: jr
Subject: Re: Call to Arms: Datetime
Date: 12 Aug 2021 02:45:00
Message: <web.6114c2df21f771715e0fed26cde94f1@news.povray.org>
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

From: clipka
Subject: Re: Call to Arms: Datetime
Date: 12 Aug 2021 03:06:51
Message: <6114c88b$1@news.povray.org>
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

From: Ton
Subject: Re: Call to Arms: Datetime
Date: 12 Aug 2021 03:15:00
Message: <web.6114c9ad21f77171152670647597fb06@news.povray.org>
"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

From: clipka
Subject: Re: Call to Arms: Datetime
Date: 12 Aug 2021 04:19:33
Message: <6114d995$1@news.povray.org>
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

From: clipka
Subject: Re: Call to Arms: Datetime
Date: 12 Aug 2021 06:58:14
Message: <6114fec6$1@news.povray.org>
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

From: jr
Subject: Re: Call to Arms: Datetime
Date: 12 Aug 2021 07:35:00
Message: <web.6115069021f771715e0fed26cde94f1@news.povray.org>
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

From: Cousin Ricky
Subject: Re: Call to Arms: Datetime
Date: 12 Aug 2021 21:48:10
Message: <6115cf5a$1@news.povray.org>
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

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.