Re: Re: sorting mm/dd/yy

[merlyn]

Depends on the range. If you can keep it within 1970 through 2038, then Unix internal time is a pretty good choice.

-- Randal L. Schwartz, Perl hacker

[royalanjr]

That is what I have been doing at the moment. I use Time:ParseDate to turn the date into epoch and store that. Then when I need the formated into something a human can understand, I use localtime() to change it back.

Someone changed the time zone on the server and it knocked all the dates out of whack. I had to write a script to make up for the time zone hour shift to make the dates right.

Now, did I just do something bone-headed when I chose that scheme for the dates, or what?

Roy Alan

[Hrunting]

I may be wrong here, so umm, don't shoot me, but I believe that epoch timestamps are always given for UTC. Time::ParseDate does some manipulation depending on what your timezone, but there's a whole lot of options to tell T::PD how to handle the input time, so you could tell it that all dates being given to it are from a certain timezone (ie. before the date that you changed the timezone, tell T:PD to use one timezone, afterwords, tell it to use another) and that should pretty much straighten out any inconsistencies you have.

I might be wrong about the epoch thing, but you can most certainly make up for shifts like that in T:PD itself.