Displaying Dates Using User Selected Timezones in Laravel 4

Let me start by saying, you can safely stop worrying about user selected timezones if you are using Laravel 4+. I just spent a few hours trying to determine what was generally the most accepted method to store and display dates using a users own timezone. As it turns out, it is way too easy. So much so that I was finding it difficult to locate up to date Laravel 4 discussions on the topic.

So in case you are as thick as I am, here it is, all spelled out for you.

Important First Step: Set the timezone in app/config/app.php to your preferred timezone (or leave it at UTC if you want) keeping in mind that you will never change this, and you will never do something terrible like Config::set(‘app.timezone’, Auth::user()->timezone); anywhere in your application.

Using the following users table as an example, assume that we want to show foobazed_at to the user using their selected timezone:

CREATE TABLE `users` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `username` varchar(255) NOT NULL,
  `locale` varchar(255) NOT NULL DEFAULT 'en',
  `timezone` varchar(255) NOT NULL DEFAULT 'America/Toronto',
  `foobazed_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `created_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `updated_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `deleted_at` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`),

Laravel by default converts created_at, updated_at, and deleted_at columns to instances of Carbon, which, not knowing what Carbon was at the time didn’t mean a whole lot to me. Well, let me tell you… Carbon is awesome.

Instead of doing the following to display the created_at date (which will show the date in the default application timezone):

echo User::find(1)->created_at;

You can simply do this to get created_at in the users own preferred timezone:

echo User::find(1)->created_at->timezone(Auth::user()->timezone);

This is all well and good for the default columns, but what about our foobazed_at date? Easy. In your model (in this case the User model at app/models/User.php) add the following method:

public function getDates()
    return array('foobazed_at', static::CREATED_AT, static::UPDATED_AT, static::DELETED_AT);

That’s it! Any time you want to display foobazed_at you can simply do this:

echo User::find(1)->foobazed_at->timezone(Auth::user()->timezone);

I hope this is useful to someone else.

Cleaning Up Is Hard To Do

Linux TuxI have been administering Linux servers for a while now so coming across a new problem is both exciting and stressful, especially when that problem is on a high demand production server. I recently came across one of these scenarios, and was surprised how difficult it was to solve.

I had a single directory on a server that contained millions and millions of tiny 32Kb text files (which were actually non-sharded PHP session files that didn’t get caught in garbage collection, and went unnoticed for months on a busy server). The interim fix to that problem was easy:

mv /var/php/sessions /var/php/sessions.evil && mkdir /var/php/sessions

The real problem was that I was left with this sessions.evil directory that I couldn’t delete, ignore in snapshot backups, or even list of the contents of because there were just too many files and going anywhere near it would use too much disk I/O and cause the load on the server to spike.

After using / writing various Bash, Python, PHP, etc, scripts that caused too much load on the server I happened across this genius solution by Zhenyu Lee (and a comment by Paul Reiber)… to use rsync instead of rm, find, xargs, etc:

On a CentOS box and using my example directory of /var/php/sessions.evil, which was owned by root:apache do this:

cd /var/php
mkdir empty_dir
chown root:apache empty_dir
rsync -vvvv -a –delete empty_dir/ sessions.evil/

Depending on how many files are in your sessions.evil directory this could take a while (2 days in my case), but the 5 minute load average on the server stayed between a manageable 2.0 and 3.0. My twist to Zhenyu’s solution was to add some verbosity (-vvvv) in there so I could tell that rsync was actually doing something.

Paul’s next comments are important though, so once rsync is eventually done mirroring your sessions.evil directory with your empty_dir pay attention:

rmdir sessions.evil
mkdir sessions.evil
rmdir sessions.evil empty_dir

The first rmdir sessions.evil will cause a bit of a load average spike for a few minutes, but once it’s gone… whew.

Well there you go, happy rsyncing, and a huge thanks to Zhenyu Lee for posting that unique and brilliant solution.