views:

112

answers:

2

For most of my tasks I find it much easier to work with date and time in the epoch format:

  • it's trivial to calculate timespan
  • or determine if some event happened before or after another,
  • I don't have to deal with time-zone issues if the data comes from different geographical sources,
  • in case of scripting languages what I usually get from database when I request a datetime-typed column is a string that I need to parse in order to work with it.
  • This list can go on, but for me in order to keep my code portable that's enough to ditch database's native datetime format and store date and time as integer. What do you guys think?

    A: 

    You should be able to solve the time zone issue by using UTC datetimes. I know C has a function for converting epoch times to UTC. I couldn't find one to go the other way, which confuses me.

    clahey
    A: 

    I think I'm so use to proper Model objects and methods in MVC these dates and times functionality becomes trivial. I depend on the date & time library to the calculations. There's very few times where I have to write my own and and actually those times I overlooked the fact that the functionality was in the library already. If you are using PHP grab the date and time library from the Zend Framework. Once you have developed your model reuse it. Then you don't care how the date and time is stored in the DB.

    Clutch
    What if I need to access the same data from PHP and Perl? Also bringing extra layer of Date objects effects performance - it's ok for few records, but makes difference on large data sets
    zakovyrya
    In my job I jump from PHP to Perl and back a lot and most PHP code can easily be translated to Perl. Regarding performance abstracting is hardly the bottle neck. If things are properly abstract increasing the performance of the code is easier because model can be refactored without disturbing the other parts of the app. Also great for testing.
    Clutch