Make WordPress Core

#47191 closed defect (bug) (wontfix)

date and time of next time change

Reported by: hupe13 Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.2
Component: Date/Time Keywords:
Focuses: Cc:


The time of the next time change isn't correct:

Universal time (UTC) is 2019-05-08 17:57:33. Local time is 2019-05-08 19:57:33.

This timezone is currently in daylight saving time.
Standard time begins on: May 8, 2029 8:34 am. 

Change History (7)

#1 @Rarst
17 months ago

  • Keywords reporter-feedback added

Could you please elaborate which time zone are you choosing and what is the expected date?

As of right now the output seems to be accurate in my time zone (Europe/Kiev).

#2 @hupe13
17 months ago

I'm in the time zone Europe/Berlin. The expected value of beginning standard time is Oct 27, 2019 3:00 a.m.

P.S. now Wordpress 5.2.1

Last edited 17 months ago by hupe13 (previous) (diff)

#3 @Rarst
17 months ago

I cannot reproduce locally, Europe/Berlin outputs correct expected value for me.

Not sure what would cause this, possibly timezone_transitions_get() giving incorrect data over server misconfiguration or something.

You could try var_dump( timezone_transitions_get( new DateTimeZone( 'Europe/Berlin' ), time() ) ); and see if data contains expected transition upcoming.

#4 @hupe13
17 months ago

It seems correct:

array(38) {
  array(5) {
    string(24) "2019-05-22T16:27:24+0000"
    string(4) "CEST"
  array(5) {
    string(24) "2019-10-27T01:00:00+0000"
    string(3) "CET"

#5 @Rarst
17 months ago

I really don't see how it ends up off by a decade then...

Errant filter in date_i18n() possibly? Try core theme and all plugins off?

#6 @hupe13
17 months ago

  • Keywords reporter-feedback removed

It seems to be a bug in php 7.3 (7.3.4) and the timezone "Europe/Berlin".
It works with php 7.2 (7.2.17). And it works correct with php73 and "Europe/Kiev".
Failing function is timezone_transitions_get( $date_time_zone_selected )

#7 @Rarst
17 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I've run it through eval and output is consistent and correct on all versions from 7.1.25 to 7.3.5 https://3v4l.org/iRemv so this doesn't look like PHP core code bug.

Back to above - likely a server/PHP issue with timezonedb (compiled into that PHP version or installed separately) specifically.

Unfortunately I don't think this is actionable in WP core, since we rely on upstream call to provide that data and trying to double check it would be prohibitively complicated (like a network request to a separate system).

Note: See TracTickets for help on using tickets.