|
in format():
http://php.net/intldateformatter
on timezones:
http://trac.agavi.org/ticket/1008
http://trac.agavi.org/changeset/3659
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.
|