On DevShed.com today there's a new article posted looking at methods for running scheduled jobs based on responses to this forum post.

I have a webpage form that requires a date and time to be submitted. When it's submitted I need the back-end to run a script at the time and date specified. Have you ever needed to do something like this?

Some recommendations already posted include:

• The UNIX "at" command
• Setting up a queue system to manage the processes (using something similar to Gearman
• Setting up a cron job to handle the periodic execution of the script.

On PHPMaster.com today there's a new tutorial by Sean Hudgston about working with dates and times via the PHP date functions and how they cooperate with dates/times from a MySQL database.

When working in any programming language, dealing with dates and time is often a trivial and simple task. That is, until time zones have to be supported. Fortunately, PHP has one of the most potent set of date/time tools that help you deal with all sorts of time-related issues: Unix timestamps, formatting dates for human consumption, displaying times with time zones, the difference between now and the second Tuesday of next month, etc. In this article I'll introduce you to the basics of PHP's time functions (time(), mktime(), and date()) and their object-oriented counterparts, and then take a look at MySQL dates and show you how to make them play nicely with PHP.

His examples include how to get the current Unix time, formatting dates/times, making timestamps and working with the more powerful DateTime objects. On the MySQL front, he shows the result of a normal date select, one using the "unix_timestamp" function and how to shift the result based on the user's timezone.

In a new post to his blog Sameer Borate includes a handy bit of code you can use to split up a large MySQL dump file into smaller, easier to digest chunks.

One of the frustrating things with working with MySQL is of importing large sql dump files. Either you get a 'max execution time exceeded' error from PHP or a 'Max_allowed_packet_size' from MySQL. In a recent task I needed to import a table of around a million records on a remote host, which quickly became an exercise in frustration due to various limitations on the server. SSH was of no help as changing the configuration files was restricted to the root user. My last resort was to split the huge 'INSERT' statements into smaller size files.

His script needs a little extra time to run (he sets max execute to 600 seconds) and takes the SQL file in line by line, splitting them back out to over files based on a "count" value - "dump-split-*". Depending on the size of your files, using something like this might not be an option. You might need something more like the command line "split" feature to keep it outside of PHP's memory management all together.

Hannes Magnusson has a new post today about an interesting feature of the PHP documentation some might not have known existed - manual pages (man) for PHP functions/methods for unix systems.

For a while I had vim configured to run reflection when I hit "K", but after the PHP documentation team released unix manual pages for PHP I now get the manual page in all its glory; function description, parameter descriptions, return values, examples, notes, see also and everything you are used to see from the online manual. Its awesome.

These manual pages aren't installed by default, so you'll have to grab the download from the PEAR channel for the PHP documentation (doc.php.net/pman). If you're wanting to use it in VIM, you'll also need to change the keywordprg setting to "pman".

Based on a fix for a recent bug, Derick Rethans wanted to clear up something about the Unix Epoc's definition and how it relates to the UTC time zone.

While right now it is proper to define the Unix Epoch at "1970-01-01 00:00:00 UTC", UTC wasn't actually defined until 1972. So it would be more correct to define the Unix Epoch as "the number of seconds elapsed since midnight proleptic Coordinated Universal Time (UTC) of January 1, 1970, not counting leap seconds." (from Wikipedia).

He talks about the calendar PHP uses internally and how dates predating it's use don't make much sense either (as well as the modified version PHP uses that includes "year zero").

On the SitePoint PHP blog today Troels Knak-Nielsen has a quick tip for those looking for a way to have their command-line PHP scripts be more interactive.

Just a quick tip, since I spent a good hour figuring this out recently. PHP has no native way of doing an interactive password prompt, when running as CLI. You can however use bash for the task.

His method (for both Windows and Unix systems) uses shell_exec command to run a VB Script/bash command that handles the password prompt for the PHP script. The result is then passed back into a variable and returned back to the calling application.

Derick Rethans one of the go-to guys for working with time in PHP has made this new post about something 2008 picked up along the way to 2009 - a leap second.

The start of this new year started with some buzz about a leap second being introduced between Dec 31st 2008, 23:59:59 and Jan 1st 2009, 00:00:00. I've had people ask where this leap second actually comes from, and whether you need to worry about it in your applications. To understand leap seconds means, unfortunately, understanding how time is actually kept.

He ponints out one of the major problems - how time is kept. With variants of Universal Time, it makes it hard to track down what's "right". He breaks out the difference between other time storage methods and the unix time that PHP can use (that counts the number of seconds since Jan 1st 1970) and how the leap second was handled for each.

Permissions in Unix-based systems have become one of the standard models for development all over the world. They're simple to learn and use while being extremely powerful at the same time. In this new article (as contributed by Eric Potvin) from PHPBuilder.com today, they bring this power to the realm of PHP with bitmasks.

Bitmasking is a very useful method to emulate Unix-style file permissions (read/write/execute for example). What's nice about a PHP implementation is that you can configure your own bitmasks and use them for any kind of permissions in your scripts and applications. The implementation is relatively simple as well.

They start by defining a few of the permission levels (add/delete/denied) in PHP constants before showing the bitMask() function you can use to check a user's permissions. They also include some simple pseudo-code to show how it's used. For more information, check out the complete article here.