thr3ads.net - R devel - [Rd] Non-deterministic POSIXlt tzone in Europe/London around UTC 0 [Jan 2026]

If this information is useful, please help other people find it:
Share via:
Georgi Boshnakov
2026-Jan-18 12:08 UTC
[Rd] Non-deterministic POSIXlt tzone in Europe/London around UTC 0

> For the example  as.POSIXlt(1) , it is clearly wrong as  Jan 1  isnot 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"...

Indeed, Jan 1 is not summer but it was 'summer time' then. Around
1969-1970 there had been
an experiment in the UK to drop the switch from/to summer time and stay
permanently in GMT+1.
so the whole years were in summer time.

Georgi Boshnakov

------------------------------

Message: 4
Date: Sat, 17 Jan 2026 22:02:45 +0100
From: Martin Maechler <maechler at stat.math.ethz.ch>
To: Ben Bolker <bbolker at gmail.com>
Cc: <r-devel at r-project.org>
Subject: Re: [Rd]  Non-deterministic POSIXlt tzone in Europe/London
        around UTC 0
Message-ID: <26987.63733.576349.826262 at stat.math.ethz.ch>
Content-Type: text/plain; charset="us-ascii"
>>>>> 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://urldefense.com/v3/__https://people.math.ethz.ch/*maechler/R/tz/tz.R__;fg!!PDiH4ENfjr2_Jw!DsL6aUImJ9mtOi2fEAHS7ugtedE6xRKuNJXKZ1prDgVCGxV_tR2V8D6cvIRpnhIDbScni2bkezrQgcpB5zjecYIvvlzHjN3BP7eDx2qlbnY$
[people[.]math[.]ethz[.]ch]
e.g.,

 
download.file("https://urldefense.com/v3/__https://people.math.ethz.ch/*maechler/R/tz/tz.R__;fg!!PDiH4ENfjr2_Jw!DsL6aUImJ9mtOi2fEAHS7ugtedE6xRKuNJXKZ1prDgVCGxV_tR2V8D6cvIRpnhIDbScni2bkezrQgcpB5zjecYIvvlzHjN3BP7eDx2qlbnY$
[people[.]math[.]ethz[.]ch]",
                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
R devel - Jan 2026 - Non-deterministic POSIXlt tzone in Europe/London around UTC 0

[Rd] Non-deterministic POSIXlt tzone in Europe/London around UTC 0
