I think we abandoned DB-native date formats for an INT simply because of compatibility. It's easier to handle converting to and from INT and date on the DB side across platforms than handling timezones across platforms. At least, that's the impression I got and the only rationale I can think of. I could, of course, be totally wrong.
On Sun, Sep 14, 2008 at 3:30 PM, Andy C <[EMAIL PROTECTED]> wrote: > > I wasn't asking why it is unsigned - I'm asking why a date/time is > being represented as a number. > > On Sep 14, 8:26 pm, Andrew da Silva <[EMAIL PROTECTED]> wrote: > > It's quite simple, it's unsigned because Unix epoch can't be negative. > > > > Only problem with using Unix epoch is year 2038 when it will end... > > > > On Sep 14, 3:17 pm, Andy C <[EMAIL PROTECTED]> wrote: > > > > > I find the design decision to change the data type of the > > > posts.pubdate column (et al) to an unsigned integer bizarre in the > > > extreme. > > > > > In modern databases, a date is normally represented a date which makes > > > sense. For example, this change now makes using SQL to select posts > > > difficult. > > > > > I don't doubt PHP has built in functions to convert Unix epoch numbers > > > to dates and times in lots of formats. > > > > > Don't get me wrong - I am now on the latest SVN and like the timezone > > > support (and scheduled posts) but out of idle curiosity, what was the > > > rationale for this ? > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
