1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-28 01:32:42 +01:00
phorge-phorge/src/view/viewutils.php

95 lines
2.6 KiB
PHP
Raw Normal View History

2011-01-31 03:24:57 +01:00
<?php
function phabricator_date($epoch, PhabricatorUser $user) {
return phabricator_format_local_time(
$epoch,
$user,
phutil_date_format($epoch));
}
function phabricator_relative_date($epoch, $user, $on = false) {
static $today;
static $yesterday;
if (!$today || !$yesterday) {
$now = time();
$today = phabricator_date($now, $user);
$yesterday = phabricator_date($now - 86400, $user);
}
$date = phabricator_date($epoch, $user);
if ($date === $today) {
return 'today';
}
if ($date === $yesterday) {
return 'yesterday';
}
return (($on ? 'on ' : '').$date);
}
function phabricator_time($epoch, $user) {
Continue modernizing application access to user preferences Summary: Ref T4103. This is just incremental cleanup: - Add "internal" settings, which aren't editable via the UI. They can still do validation and run through the normal pathway. Move a couple settings to use this. - Remove `getPreference()` on `PhabricatorUser`, which was a sort of prototype version of `getUserSetting()`. - Make `getUserSetting()` validate setting values before returning them, to improve robustness if we change allowable values later. - Add a user setting cache, since reading user settings was getting fairly expensive on Calendar. - Improve performance of setting validation for timezone setting (don't require building/computing all timezone offsets). - Since we have the cache anyway, make the timezone override a little more general in its approach. - Move editor stuff to use `getUserSetting()`. Test Plan: - Changed search scopes. - Reconciled local and server timezone settings by ignoring and changing timezones. - Changed date/time settings, browsed Calendar, queried date ranges. - Verified editor links generate properly in Diffusion. - Browsed around with time/date settings looking at timestamps. - Grepped for `getPreference()`, nuked all the ones coming off `$user` or `$viewer` that I could find. - Changed accessiblity to high-contrast colors. - Ran all unit tests. - Grepped for removed constants. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4103 Differential Revision: https://secure.phabricator.com/D16015
2016-06-03 02:12:15 +02:00
$time_key = PhabricatorTimeFormatSetting::SETTINGKEY;
return phabricator_format_local_time(
$epoch,
$user,
Continue modernizing application access to user preferences Summary: Ref T4103. This is just incremental cleanup: - Add "internal" settings, which aren't editable via the UI. They can still do validation and run through the normal pathway. Move a couple settings to use this. - Remove `getPreference()` on `PhabricatorUser`, which was a sort of prototype version of `getUserSetting()`. - Make `getUserSetting()` validate setting values before returning them, to improve robustness if we change allowable values later. - Add a user setting cache, since reading user settings was getting fairly expensive on Calendar. - Improve performance of setting validation for timezone setting (don't require building/computing all timezone offsets). - Since we have the cache anyway, make the timezone override a little more general in its approach. - Move editor stuff to use `getUserSetting()`. Test Plan: - Changed search scopes. - Reconciled local and server timezone settings by ignoring and changing timezones. - Changed date/time settings, browsed Calendar, queried date ranges. - Verified editor links generate properly in Diffusion. - Browsed around with time/date settings looking at timestamps. - Grepped for `getPreference()`, nuked all the ones coming off `$user` or `$viewer` that I could find. - Changed accessiblity to high-contrast colors. - Ran all unit tests. - Grepped for removed constants. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4103 Differential Revision: https://secure.phabricator.com/D16015
2016-06-03 02:12:15 +02:00
$user->getUserSetting($time_key));
}
function phabricator_datetime($epoch, $user) {
Continue modernizing application access to user preferences Summary: Ref T4103. This is just incremental cleanup: - Add "internal" settings, which aren't editable via the UI. They can still do validation and run through the normal pathway. Move a couple settings to use this. - Remove `getPreference()` on `PhabricatorUser`, which was a sort of prototype version of `getUserSetting()`. - Make `getUserSetting()` validate setting values before returning them, to improve robustness if we change allowable values later. - Add a user setting cache, since reading user settings was getting fairly expensive on Calendar. - Improve performance of setting validation for timezone setting (don't require building/computing all timezone offsets). - Since we have the cache anyway, make the timezone override a little more general in its approach. - Move editor stuff to use `getUserSetting()`. Test Plan: - Changed search scopes. - Reconciled local and server timezone settings by ignoring and changing timezones. - Changed date/time settings, browsed Calendar, queried date ranges. - Verified editor links generate properly in Diffusion. - Browsed around with time/date settings looking at timestamps. - Grepped for `getPreference()`, nuked all the ones coming off `$user` or `$viewer` that I could find. - Changed accessiblity to high-contrast colors. - Ran all unit tests. - Grepped for removed constants. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4103 Differential Revision: https://secure.phabricator.com/D16015
2016-06-03 02:12:15 +02:00
$time_key = PhabricatorTimeFormatSetting::SETTINGKEY;
return phabricator_format_local_time(
$epoch,
$user,
pht('%s, %s',
phutil_date_format($epoch),
Continue modernizing application access to user preferences Summary: Ref T4103. This is just incremental cleanup: - Add "internal" settings, which aren't editable via the UI. They can still do validation and run through the normal pathway. Move a couple settings to use this. - Remove `getPreference()` on `PhabricatorUser`, which was a sort of prototype version of `getUserSetting()`. - Make `getUserSetting()` validate setting values before returning them, to improve robustness if we change allowable values later. - Add a user setting cache, since reading user settings was getting fairly expensive on Calendar. - Improve performance of setting validation for timezone setting (don't require building/computing all timezone offsets). - Since we have the cache anyway, make the timezone override a little more general in its approach. - Move editor stuff to use `getUserSetting()`. Test Plan: - Changed search scopes. - Reconciled local and server timezone settings by ignoring and changing timezones. - Changed date/time settings, browsed Calendar, queried date ranges. - Verified editor links generate properly in Diffusion. - Browsed around with time/date settings looking at timestamps. - Grepped for `getPreference()`, nuked all the ones coming off `$user` or `$viewer` that I could find. - Changed accessiblity to high-contrast colors. - Ran all unit tests. - Grepped for removed constants. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4103 Differential Revision: https://secure.phabricator.com/D16015
2016-06-03 02:12:15 +02:00
$user->getUserSetting($time_key)));
}
/**
* This function does not usually need to be called directly. Instead, call
* @{function:phabricator_date}, @{function:phabricator_time}, or
* @{function:phabricator_datetime}.
*
* @param int Unix epoch timestamp.
* @param PhabricatorUser User viewing the timestamp.
* @param string Date format, as per DateTime class.
* @return string Formatted, local date/time.
*/
function phabricator_format_local_time($epoch, $user, $format) {
if (!$epoch) {
// If we're missing date information for something, the DateTime class will
// throw an exception when we try to construct an object. Since this is a
// display function, just return an empty string.
return '';
}
$user_zone = $user->getTimezoneIdentifier();
static $zones = array();
if (empty($zones[$user_zone])) {
$zones[$user_zone] = new DateTimeZone($user_zone);
}
$zone = $zones[$user_zone];
// NOTE: Although DateTime takes a second DateTimeZone parameter to its
// constructor, it ignores it if the date string includes timezone
// information. Further, it treats epoch timestamps ("@946684800") as having
// a UTC timezone. Set the timezone explicitly after constructing the object.
try {
$date = new DateTime('@'.$epoch);
} catch (Exception $ex) {
// NOTE: DateTime throws an empty exception if the format is invalid,
// just replace it with a useful one.
throw new Exception(
pht("Construction of a DateTime() with epoch '%s' ".
"raised an exception.", $epoch));
}
$date->setTimezone($zone);
return PhutilTranslator::getInstance()->translateDate($format, $date);
}