>>>>> Ben Bolker
>>>>> on Wed, 14 Jan 2026 18:21:37 -0500 writes:
> It seems not so much non-deterministic, as different on the first vs.
> following invocations ...
Thank you, Ben! Indeed, I can confirm "deterministic",
but even stranger (see below)..
> $ cat tz.R
> Sys.setenv(TZ="Europe/London")
> for (i in 1:10) {
> print(attr(as.POSIXlt(as.numeric(1:10)), 'tzone'))
> $ Rscript tz.R
> [1] "Europe/London" "GMT" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> $ Rscript tz.R
> [1] "Europe/London" "GMT" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> $ Rscript tz.R
> [1] "Europe/London" "GMT" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> [1] "Europe/London" "BST" "BST"
> On 1/14/26 17:47, Michael Chirico via R-devel wrote:
>> As a test case I have code running 'as.POSIXlt(1:10)', which can
>> unfortunately produce non-deterministic results:
>>
>> TZ=Europe/London R
>> attr(as.POSIXlt(as.numeric(1:10)), 'tzone')
>> # [1] "Europe/London" "GMT" "BST"
>> attr(as.POSIXlt(as.numeric(1:10)), 'tzone')
>> # [1] "Europe/London" "BST" "BST"
>>
>> Is this intended behavior? I don't see this possibility described in
>> any of ?DateTimeClasses, ?strptime, ?timezones, or ?as.POSIXlt. Some
>> caching is mentioned around .sys.timezone, but the above snippets
>> don't have any relationship that I can see.
This is true. I've also checked .sys.timezone and not seen
anything.
For those (like me who did not know):
BST today is "British Summer Time" (and *not* "British Standard
Time" as I first guessed).
For the example as.POSIXlt(1) , it is clearly wrong as Jan 1 is
not summer time in London ... OTOH, at that time maybe there was
confusion .. (?).
I see that indeed `gmtoff = 3600` which would also say that
London was off UTC by 1 hour, as in "real summer time"...
The behaviour we see is actually much older than .sys.timezone
(which exists only since R 4.0.0);
The format()ing / print()ing of such times also changes, but
seems to be *correct* (depending on "Summer" / "Winter") and
doing so +- correctly (see below).. whereas indeed there must be C level
state variable which is at the first call and then used...
You can use my R script tz.R (which I also attach with MIME type text/plain)
and also provide, to be safe (from E-mail mangling etc):
Alternatively use
https://people.math.ethz.ch/~maechler/R/tz/tz.R
e.g.,
download.file("https://people.math.ethz.ch/~maechler/R/tz/tz.R";,
destfile="/tmp/tz.R")
When I run it with a close to 10 year old version of R
via
`R-3.3.0 RHOME`/bin/Rscript --vanilla tz.R
I get
R version 3.3.0 (2016-05-03)
"Non-deterministic" POSIXlt tzone in Europe/London around UTC 0
Europe/London
-------- no print(), only cat(.. format(*) ..) : -------------------------
-2, lt(5.3949e+06): 1970-03-04 11:34:40 BST | GMT BST =>> changed to BST BST
-1, lt(5.5123e+06): 1970-03-05 20:12:20 BST | BST BST
0, lt( 6e+06): 1970-03-11 11:40:00 BST | BST BST
1, lt(6.5123e+06): 1970-03-17 09:59:00 BST | BST BST
2, lt(7.3949e+06): 1970-03-27 15:08:00 BST | BST BST
3, lt(1.0499e+07): 1970-05-02 13:17:00 BST | BST BST
4, lt(2.0636e+07): 1970-08-27 21:16:00 BST | BST BST
5, lt(4.7062e+07): 1971-06-29 17:55:00 BST | BST BST
6, lt(1.0496e+08): 1973-04-29 19:24:00 BST | BST BST =>> changed to GMT BST
7, lt( 2.169e+08): 1976-11-15 09:33:00 GMT | GMT BST
8, lt(4.1436e+08): 1983-02-17 19:12:00 GMT | GMT BST
9, lt(7.3916e+08): 1993-06-04 04:31:00 BST | GMT BST
10, lt( 1.245e+09): 2009-06-14 18:20:00 BST | GMT BST
9, lt(7.3916e+08): 1993-06-04 04:31:00 BST | GMT BST
8, lt(4.1436e+08): 1983-02-17 19:12:00 GMT | GMT BST
7, lt( 2.169e+08): 1976-11-15 09:33:00 GMT | GMT BST
6, lt(1.0496e+08): 1973-04-29 19:24:00 BST | GMT BST
5, lt(4.7062e+07): 1971-06-29 17:55:00 BST | GMT BST =>> changed to BST BST
4, lt(2.0636e+07): 1970-08-27 21:16:00 BST | BST BST
3, lt(1.0499e+07): 1970-05-02 13:17:00 BST | BST BST
2, lt(7.3949e+06): 1970-03-27 15:08:00 BST | BST BST
1, lt(6.5123e+06): 1970-03-17 09:59:00 BST | BST BST
0, lt( 6e+06): 1970-03-11 11:40:00 BST | BST BST
-1, lt(5.5123e+06): 1970-03-05 20:12:20 BST | BST BST
-2, lt(5.3949e+06): 1970-03-04 11:34:40 BST | BST BST
$
and this *identical* (apart from the R.version.string at the start)
to running it in my current version of R-devel and also to
running R version 3.1.0 (2014-04-10).
It seems the "state changing" effect happens
indicated by "==> changed ..." above only when the
current time is relatively close to 1970-01-01 (the POSIXct time origin).
So, at least this is not at all a new problem,
*BUT* it also not "infinitely old":
It does *not* happen for me, with R 3.0.0, where I see
$ `R-3.0.0 RHOME`/bin/Rscript --vanilla tz.R
R version 3.0.0 (2013-04-03)
"Non-deterministic" POSIXlt tzone in Europe/London around UTC 0
Europe/London
-------- no print(), only cat(.. format(*) ..) : -------------------------
-2, lt(5.3949e+06): 1970-03-04 11:34:40 BST | BST BST
-1, lt(5.5123e+06): 1970-03-05 20:12:20 BST | BST BST
0, lt( 6e+06): 1970-03-11 11:40:00 BST | BST BST
1, lt(6.5123e+06): 1970-03-17 09:59:00 BST | BST BST
2, lt(7.3949e+06): 1970-03-27 15:08:00 BST | BST BST
3, lt(1.0499e+07): 1970-05-02 13:17:00 BST | BST BST
4, lt(2.0636e+07): 1970-08-27 21:16:00 BST | BST BST
5, lt(4.7062e+07): 1971-06-29 17:55:00 BST | BST BST
6, lt(1.0496e+08): 1973-04-29 19:24:00 BST | GMT BST
7, lt( 2.169e+08): 1976-11-15 09:33:00 GMT | GMT BST
8, lt(4.1436e+08): 1983-02-17 19:12:00 GMT | GMT BST
9, lt(7.3916e+08): 1993-06-04 04:31:00 BST | GMT BST
10, lt( 1.245e+09): 2009-06-14 18:20:00 BST | GMT BST
9, lt(7.3916e+08): 1993-06-04 04:31:00 BST | GMT BST
8, lt(4.1436e+08): 1983-02-17 19:12:00 GMT | GMT BST
7, lt( 2.169e+08): 1976-11-15 09:33:00 GMT | GMT BST
6, lt(1.0496e+08): 1973-04-29 19:24:00 BST | GMT BST
5, lt(4.7062e+07): 1971-06-29 17:55:00 BST | BST BST
4, lt(2.0636e+07): 1970-08-27 21:16:00 BST | BST BST
3, lt(1.0499e+07): 1970-05-02 13:17:00 BST | BST BST
2, lt(7.3949e+06): 1970-03-27 15:08:00 BST | BST BST
1, lt(6.5123e+06): 1970-03-17 09:59:00 BST | BST BST
0, lt( 6e+06): 1970-03-11 11:40:00 BST | BST BST
-1, lt(5.5123e+06): 1970-03-05 20:12:20 BST | BST BST
-2, lt(5.3949e+06): 1970-03-04 11:34:40 BST | BST BST
$
(notably, no "=>> changed to ...." marks !)
The above is in the Linux default
> sessionInfo()$tzcode
[1] "system (glibc)"
OTOH, if using the R internal tzcode
[via configure --with-internal-tzcode ]
the above "=>> changed to ...." marks do *not* appear and the
tzone entries shown above are "constant", always " | GMT BST "
So, there is a problem with "system (glibc)"'s behaviour, or in
the logic of our interface to that..
.. and I am happy I see no changes to the C code (datetime.c) by me between
spring 2013 and 2014 , so chances are high that this time it was
not me ;-) ... but yes, indeed, there were quite a few changes
there, also fixing problems with tzone
(svn rev 62314, *622,*623, 64233,..., 65798, 65159).
............
Ok, that's enough material for a new R Bugzilla PR ..
Martin
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
