Greetings all

I have read the previous discussions on date formatting and must admit that I'm a little lost by it all. I have a specific date format that I want to use, which doesn't seem to appear in the discussions.

So - the format: dd/mm/yy

Could someone give me some guidance on the best way to acchieve this?

Ian

Use a date routine from the FAQ (http://webmagic.hypermart.net/dbman/db/dbfaq.cgi) or change field type to alpha, take out the &get_date part and type in the date in any format you wish.

You'll have to 'play' with one of the routines to get it into the format you want.

Thanks for the info - I'm endeavouring to look at the faq - but it seems to crash my browser each time I visit that link. I got in by logging into the site first.

The prompt about using alpha rather than date is good, but I want to make sure I can search, and order things by date - I think if I made it an alpha field I wouldn't be able to achieve this.

Ian

In the file db.cgi (or db.pl), you'll find two subroutines that you have to change.
Below are my versions, adapted for returning the date format DD/MM/YYYY:

sub get_date {
# --------------------------------------------------------
# Returns the date in the format "dd-mm-yyyy".
# Warning: If you change the default format, you must also modify the &date_to_unix
# subroutine below which converts your date format into a unix time in seconds for sorting
# purposes.
my $time = $_[0];
($time) || ($time = time);
my ($sec, $min, $hour, $day, $mon, $year, $dweek, $dyear, $daylight) = localtime($time);
my (@months) = qw!01 02 03 04 05 06 07 08 09 10 11 12!;
($day < 10) and ($day = "0$day");
$year = $year + 1900;

return "$day-$months[$mon]-$year";
}



sub date_to_unix {
# --------------------------------------------------------
# This routine must take your date format and return the time a la UNIX time().
# Some things to be careful about..
# int your values just in case to remove spaces, etc.
# catch the fatal error timelocal will generate if you have a bad date..
# don't forget that the month is indexed from 0!
#
my $date = $_[0];
my (%months) = ("01" => 0, "02" => 1, "03" => 2, "04" => 3, "05" => 4, "06" => 5,
"07" => 6, "08" => 7, "09" => 8, "10" => 9, "11" => 10,"12" => 11);
my $time;
my ($day, $mon, $year) = split(/-/, $date);
unless ($day and $mon and $year) { return undef; }
unless (defined($months{$mon})) { return undef; }

use Time::Local;
eval {
$day = int($day); $year = int($year) - 1900;
$time = timelocal(0,0,0,$day, $months{$mon}, $year);
};
if ($@) { return undef; } # Could return 0 if you want.
return ($time);
}



kellner

Thanks

This works great

However I'm now trying to get the yaer to display at 2 digits - and if I leave the + 1900 bit out, it returns a date of just '1' for 2001 - any ideas on how I could get it to display 01 anyone?

Ian

In sub get_date, this is easy, just add "$year = substr($year,-2,2)" at the end.

However, in sub date_to_unix, things are more complicated.
You have a year-format like "01" or "67". You need to get the full four-digit format for the function "timelocal" to work (or so I believe). But how do you know whether the full four digit number is "1900 + 01" or "2000 + 01"?

I don't know what sort of data you are working with, and whether you can really guarantee that you'll never have years like "1901" - that the two digits at the end of a year will never be ambiguous.
If, you can guarantee that, say, all years ranging from "00-34" are "2000+"-years, and that all years ranging from "35-99" are "1900+"-years, you could determine whether $year is in either of these ranges and then add 1900 or 2000 accordingly.

To me, this would seem a bit complicated, and I'd rather stick with a full four digit year format. But then again, I'm coding across centuries :-)
kellner

Thanks Heaps

I'll work on this, as I can guarantee that the dates are all 2000+ years - it's current info re dates of transport trips, and 1900 years will never come into it.

The reason for the 2 digit date is an aesthetic one - trying to take up the least amount of screen geography as possible as results are displayed as quite a wide table.

Thanks again

Ian