Clock in Russia, again ... and php5-intl

Good% time of day%.

Background

No signs of trouble. Long before tzdata was updated and all that hands could reach. But at the next moment of the clock transfer, my site began to give out Moscow time an hour more. A quick check showed that OS itself, mysql and php (the date function) return the time correctly and indicate the time zone +3 for Moscow. The dog was buried in a good extension php5-intl. The format function of the IntlDateFormatter class persistently returned the +4 time zone for Moscow.

Study

In the beginning, Google didn’t want to help me ... but soon I found out about such a beast as icu and another base of time zones, which, oddly enough, were not updated in my system. And everything would be fine ... apt-get update ... apt-get upgrade ... and ... the lack of an update for libicu FIG knows how much time. Even good people made a bug in Debian about this. But things are still there. Google stubbornly advised nothing good. Everything rested on the manual assembly of the latest version. This option was even modestly lit on Habré . As a person far from the Linux world, I almost ruined the system in an attempt to build something. In summary, with the help of a good friend lsh and joint enhanced googling, we found a simple way to update data for libicu without resorting to compilation or other shamanism.

Decision

It turned out that libicu, even being compiled with direct inclusion of timezone data, etc. inside .so, leaves it possible to slip a fresh version of them through the instructions of the folder where she could get them from. This is done through the environment variable ICU_DATA. Having found all the pieces of the puzzle and having passed a couple of unsuccessful attempts, a simple and ready-to-use solution appeared:

• You need to download the latest versions of timezone data, etc. on the link from the icu-project website.
  Files must be taken from the “le” folder (little-endian, probably), at least they came to me on a system with Intel's software and Debian x64. There is still a daddy “be” (big-endian) and a mysterious “ee” (who knows who she is for?)
  
• Place the downloaded 4 files into the directory, for example: / opt / icu / icudt48l / (for version libicu 4.8)
• Specify the appropriate environment variable:
  
  • For php-cgi, you can specify it in the system / etc / environment:
    

    ICU_DATA=/opt/icu/

    
    
  • For php-fpm in the settings of a specific worker:
    

    env[ICU_DATA]=/opt/icu/

    
    
  • For Apache, you must enable mod_env and write in htaccess:
    

    SetEnv ICU_DATA /opt/icu/

    
    
  
  

And, no, I was not mistaken placing the files in icu / icudt48l / and in the paths I specified only the icu folder. The thing is that libicu itself substitutes a folder for the ICU_DATA path based on its version (why ?!). So, in the future, when updating libicu, the folder will have to be renamed to a different name. Judging by the observation, the name of the folder is formed as:

icudt - icu data
48 - версия libicu (4.8 -> 48, 3.6 -> 36)
l - порядок байт (l - little-endian, b - big-endian)

Accordingly, you need to name the folder based on the version of libicu on your system.

Restarting php-fpm and ... profit) you can now safely remove the crutch with substitution of the Europe / Minsk timezone instead of Europe / Moscow :)

By the way, the question is, why does php-fpm ignore the global env? If anyone finds a way to specify this setting globally for all php-fpm workers, thank you very much human.

@symbix notes that if you turn off clear_env in php-fpm, then all php-fpm workers will see the global env, i.e. you don’t have to specify env [ICU_DATA] separately for each worker. But the problem is that just the workers are beginning to see the superfluous, and not just the line we need.

Oddly enough, but this simple method was difficult to google. I, like many before me, faced with this problem, tried to rebuild, pull distributions from fresh test builds, and much more. And what is even stranger is that this method is only briefly mentioned on the icu site itself . I hope I closed this question for you.

Thank you and hopeless coding!