Re: Re: Re: Perl and Compatibility w/SQL dates

This is a bit dangerous isn't it? What happens when a process accidentally updates one of the columns and not the other?

It would be safer/easier to write a function (either in perl or the db) to convert between the two formats, and only store one of them. I've not used mysql much, but unix_timestamp() might be useful there.

Regarding the original problem - getting thousands of lines into a project before discovering bugs like this is a good example of why writing tests as you go (or before you go in some cases) is such a sanity-saver. :)

Comment on Re: Re: Re: Perl and Compatibility w/SQL dates

Replies are listed 'Best First'.
Re: Re: Re: Re: Perl and Compatibility w/SQL dates by nmerriweather (Friar) on Sep 08, 2002 at 01:39 UTC
having the diff. date formats is a little dangerous indeed -- but thats my little 'sanity saver' test. i ended up killing the unix timestamp format, as i found mysql's datetime to be faster for my needs at least on my operations, getting all the info for a 'day' was much faster matching the left 10 characters in mysql to a 'yyyy-mm-dd' date than was searching where 'timestamp > daystart AND timestamp < dayend' to insert a date, i just do a 'FROM_UNIXTIME(time)' - and mysql could either spit it out as a yyyy-mm-dd or TO_UNIXTIME	[reply]

Replies are listed 'Best First'.

Re: Re: Re: Re: Perl and Compatibility w/SQL dates
by nmerriweather (Friar) on Sep 08, 2002 at 01:39 UTC

at least on my operations, getting all the info for a 'day' was much faster matching the left 10 characters in mysql to a 'yyyy-mm-dd' date than was searching where 'timestamp > daystart AND timestamp < dayend'

to insert a date, i just do a 'FROM_UNIXTIME(time)' - and mysql could either spit it out as a yyyy-mm-dd or TO_UNIXTIME

[reply]