Date.php
Copyright 2004-2017 Horde LLC (http://www.horde.org/)
See the enclosed file LICENSE for license information (LGPL). If you did not receive this file, see http://www.horde.org/licenses/lgpl21.
Tags
- author
-
Chuck Hagenbuch chuck@horde.org
- author
-
Jan Schneider jan@horde.org
- author
-
Michael J Rubinsky mrubinsk@horde.org
- category
-
Horde
- license
-
http://www.horde.org/licenses/lgpl21 LGPL
- todo
-
in format(): http://php.net/intldateformatter
- todo
-
on timezones: http://trac.agavi.org/ticket/1008 http://trac.agavi.org/changeset/3659
- todo
-
on switching to PHP::DateTime: The only thing ever stored in the database IS Unix timestamps. Doing anything other than that is unmanageable, yet some frameworks use 'server based' times in their systems, simply because they do not bother with daylight saving and only 'serve' one timezone!
The second you have to manage 'real' time across timezones then daylight saving becomes essential, BUT only on the display side! Since the browser only provides a time offset, this is useless and to be honest should simply be ignored ( until it is upgraded to provide the correct information ;) ). So we need a 'display' function that takes a simple numeric epoch, and a separate timezone id into which the epoch is to be 'converted'. My W3C mapping works simply because ADOdb then converts that to it's own simple offset abbreviation - in my case GMT or BST. As long as DateTime passes the full 64 bit number the date range from 100AD is also preserved ( and further back if 2 digit years are disabled ). If I want to display the 'real' timezone with this 'time' then I just add it in place of ADOdb's 'timezone'. I am tempted to simply adjust the ADOdb class to take a timezone in place of the simple GMT switch it currently uses.
The return path is just the reverse and simply needs to take the client display offset off prior to storage of the UTC epoch. SO we use DateTimeZone to get an offset value for the clients timezone and simply add or subtract this from a timezone agnostic display on the client end when entering new times.
It's not really feasible to store dates in specific timezone, as most national/local timezones support DST - and that is a pain to support, as eg. sorting breaks when some timestamps get repeated. That's why it's usually better to store datetimes as either UTC datetime or plain unix timestamp. I usually go with the former - using database datetime type.
Interfaces, Classes, Traits and Enums
- Horde_Date
- Horde Date wrapper/logic class, including some calculation functions.