2

I do have an old piece of PHP code (approximate 9 years) with a lot of time() and strtotime() calls. The main reason for that it was because of users being located in different timezones.

Now, I do see that a lot of people say that the new objectified library of PHP should be used instead of old/plain functions.

My question is: Did anyone who migrated code from using functional "date and time" API to the new object-oriented one encounter some big drawbacks or problems?

Alex
  • 5,510
  • 8
  • 35
  • 54
  • 1
    I'd really recommend using DateTime which makes most date and time related operations easier than using the original procedural functions – A l w a y s S u n n y Apr 05 '15 at 13:38
  • @BeingSunny I tend to agree with you but only seeing how many PHP (micro) updates you have to make to adjust timezones' changes makes me wonder... – Alex Apr 05 '15 at 13:47

2 Answers2

2

Basically the old functions are still working. Also they don't have been marked as deprecated. The advantage of the new DateTime API is the improved or simplified functionality. As long as your old application does not need this additional functionality you wouldn't need to migrate to the DateTime API.

If you want to review the code and further develop it, I would encourage you to migrate to the DateTime API for the above reasons. The only drawback that I could see is the fact that you would need to rewrite that parts of the code - and(!) test it.

hek2mgl
  • 152,036
  • 28
  • 249
  • 266
  • I'm not afraid of tinkering with the code...I'm more afraid of the fact that there a lot of timezone updates (due to different government decisions) that might need a lot of server "grooming" to avoid PHP behave strange. – Alex Apr 05 '15 at 13:52
  • Both, the time functions and the datetime api are based on the same low level code. There is no difference in the amount of server "grooming" – hek2mgl Apr 05 '15 at 13:55
  • Are there really so much time zone changes due to government decisions? – hek2mgl Apr 05 '15 at 13:56
  • Enough to feel uncomfortable. Even a single change of a timezone will make the app unusable until a PHP patch is created and installed. – Alex Apr 05 '15 at 14:32
  • Check this question: http://stackoverflow.com/questions/3564478/how-to-update-timezonedb-in-php-updating-timezones-info for this problem – Alex Apr 05 '15 at 14:34
  • Yeah, this is some *dirty sh++* I've heard about that on a Debian maintainer mailing list once, but I'm unsure what was the result. I never had to deal with such requirements. Let me try to find that mailing list for you.. – hek2mgl Apr 05 '15 at 14:35
  • I think to remember that you can configure PHP to use time zone information from OS.. – hek2mgl Apr 05 '15 at 14:36
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/74519/discussion-between-hek2mgl-and-alex). – hek2mgl Apr 05 '15 at 15:08
0

I would just store timestamps as GMT(0) all over the place, and before outputting, based on, where user is located I would reformat time value to user-fit-needs. i would get rid of whole PHP's date time ancient stuff but I would use only this call to it. Date('YdmHis'); so I could as previously stated just store timestamps all over the place. And use my CUSTOM class before outputting values.

Uh, and make sure to store Timestamp as GMT-0 so the reference point was at least consistent, and there you go, the best part of ancient code restructuring is when a new bloodline is created (computing power in novadays lets you not to delete old code but just write over and around it ... joke,)

animaacija
  • 170
  • 9
  • 25
  • Date('YdmHis') is simply using the underlying system GMT thus is not very reliable. If I would go that way I would use Date('YdmHis O') so I will have also the timezone offset added ;) – Alex Apr 05 '15 at 15:58