2012-04-04 21:14:10 +02:00
|
|
|
<?php
|
|
|
|
|
|
|
|
final class AphrontFormDateControl extends AphrontFormControl {
|
|
|
|
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
private $initialTime;
|
2012-04-04 21:14:10 +02:00
|
|
|
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
private $valueDay;
|
|
|
|
private $valueMonth;
|
|
|
|
private $valueYear;
|
|
|
|
private $valueTime;
|
|
|
|
|
|
|
|
const TIME_START_OF_DAY = 'start-of-day';
|
|
|
|
const TIME_END_OF_DAY = 'end-of-day';
|
|
|
|
const TIME_START_OF_BUSINESS = 'start-of-business';
|
|
|
|
const TIME_END_OF_BUSINESS = 'end-of-business';
|
|
|
|
|
|
|
|
public function setInitialTime($time) {
|
|
|
|
$this->initialTime = $time;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2012-04-04 21:14:10 +02:00
|
|
|
public function readValueFromRequest(AphrontRequest $request) {
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
$user = $this->user;
|
|
|
|
if (!$this->user) {
|
|
|
|
throw new Exception(
|
|
|
|
"Call setUser() before readValueFromRequest()!");
|
|
|
|
}
|
|
|
|
|
|
|
|
$user_zone = $user->getTimezoneIdentifier();
|
|
|
|
$zone = new DateTimeZone($user_zone);
|
2012-04-04 21:14:10 +02:00
|
|
|
|
|
|
|
$day = $request->getInt($this->getDayInputName());
|
|
|
|
$month = $request->getInt($this->getMonthInputName());
|
|
|
|
$year = $request->getInt($this->getYearInputName());
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
$time = $request->getStr($this->getTimeInputName());
|
2012-04-04 21:14:10 +02:00
|
|
|
|
|
|
|
$err = $this->getError();
|
|
|
|
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
if ($day || $month || $year || $time) {
|
|
|
|
$this->valueDay = $day;
|
|
|
|
$this->valueMonth = $month;
|
|
|
|
$this->valueYear = $year;
|
|
|
|
$this->valueTime = $time;
|
2012-04-04 21:14:10 +02:00
|
|
|
|
|
|
|
// Assume invalid.
|
|
|
|
$err = 'Invalid';
|
|
|
|
|
|
|
|
try {
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
$date = new DateTime("{$year}-{$month}-{$day} {$time}", $zone);
|
|
|
|
$value = $date->format('U');
|
2012-04-04 21:14:10 +02:00
|
|
|
} catch (Exception $ex) {
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
$value = null;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($value) {
|
|
|
|
$this->setValue($value);
|
|
|
|
$err = null;
|
|
|
|
} else {
|
|
|
|
$this->setValue(null);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// TODO: We could eventually allow these to be customized per install or
|
|
|
|
// per user or both, but let's wait and see.
|
|
|
|
switch ($this->initialTime) {
|
|
|
|
case self::TIME_START_OF_DAY:
|
|
|
|
default:
|
|
|
|
$time = '12:00 AM';
|
|
|
|
break;
|
|
|
|
case self::TIME_START_OF_BUSINESS:
|
|
|
|
$time = '9:00 AM';
|
|
|
|
break;
|
|
|
|
case self::TIME_END_OF_BUSINESS:
|
|
|
|
$time = '5:00 PM';
|
|
|
|
break;
|
|
|
|
case self::TIME_END_OF_DAY:
|
|
|
|
$time = '11:59 PM';
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
$today = $this->formatTime(time(), 'Y-m-d');
|
|
|
|
try {
|
|
|
|
$date = new DateTime("{$today} {$time}", $zone);
|
|
|
|
$value = $date->format('U');
|
|
|
|
} catch (Exception $ex) {
|
|
|
|
$value = null;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($value) {
|
|
|
|
$this->setValue($value);
|
|
|
|
} else {
|
|
|
|
$this->setValue(null);
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
$this->setError($err);
|
|
|
|
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
return $this->getValue();
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
protected function getCustomControlClass() {
|
|
|
|
return 'aphront-form-control-date';
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
public function setValue($epoch) {
|
|
|
|
$result = parent::setValue($epoch);
|
2012-04-04 21:14:10 +02:00
|
|
|
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
if ($epoch === null) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
$readable = $this->formatTime($epoch, 'Y!m!d!g:i A');
|
|
|
|
$readable = explode('!', $readable, 4);
|
|
|
|
|
|
|
|
$this->valueYear = $readable[0];
|
|
|
|
$this->valueMonth = $readable[1];
|
|
|
|
$this->valueDay = $readable[2];
|
|
|
|
$this->valueTime = $readable[3];
|
|
|
|
|
|
|
|
return $result;
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
private function getMinYear() {
|
|
|
|
$cur_year = $this->formatTime(
|
|
|
|
time(),
|
|
|
|
'Y');
|
|
|
|
$val_year = $this->getYearInputValue();
|
|
|
|
|
|
|
|
return min($cur_year, $val_year) - 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
private function getMaxYear() {
|
|
|
|
$cur_year = $this->formatTime(
|
|
|
|
time(),
|
|
|
|
'Y');
|
|
|
|
$val_year = $this->getYearInputValue();
|
|
|
|
|
|
|
|
return max($cur_year, $val_year) + 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
private function getDayInputValue() {
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
return $this->valueDay;
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
private function getMonthInputValue() {
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
return $this->valueMonth;
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
private function getYearInputValue() {
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
return $this->valueYear;
|
|
|
|
}
|
|
|
|
|
|
|
|
private function getTimeInputValue() {
|
|
|
|
return $this->valueTime;
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
private function formatTime($epoch, $fmt) {
|
|
|
|
return phabricator_format_local_time(
|
|
|
|
$epoch,
|
|
|
|
$this->user,
|
|
|
|
$fmt);
|
|
|
|
}
|
|
|
|
|
|
|
|
private function getDayInputName() {
|
|
|
|
return $this->getName().'_d';
|
|
|
|
}
|
|
|
|
|
|
|
|
private function getMonthInputName() {
|
|
|
|
return $this->getName().'_m';
|
|
|
|
}
|
|
|
|
|
|
|
|
private function getYearInputName() {
|
|
|
|
return $this->getName().'_y';
|
|
|
|
}
|
|
|
|
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
private function getTimeInputName() {
|
|
|
|
return $this->getName().'_t';
|
|
|
|
}
|
|
|
|
|
2012-04-04 21:14:10 +02:00
|
|
|
protected function renderInput() {
|
|
|
|
$min_year = $this->getMinYear();
|
|
|
|
$max_year = $this->getMaxYear();
|
|
|
|
|
|
|
|
$days = range(1, 31);
|
2013-01-26 02:06:55 +01:00
|
|
|
$days = array_fuse($days);
|
2012-04-04 21:14:10 +02:00
|
|
|
|
|
|
|
$months = array(
|
|
|
|
1 => 'Jan',
|
|
|
|
2 => 'Feb',
|
|
|
|
3 => 'Mar',
|
|
|
|
4 => 'Apr',
|
|
|
|
5 => 'May',
|
|
|
|
6 => 'Jun',
|
|
|
|
7 => 'Jul',
|
|
|
|
8 => 'Aug',
|
|
|
|
9 => 'Sep',
|
|
|
|
10 => 'Oct',
|
|
|
|
11 => 'Nov',
|
|
|
|
12 => 'Dec',
|
|
|
|
);
|
|
|
|
|
|
|
|
$years = range($this->getMinYear(), $this->getMaxYear());
|
2013-01-26 02:06:55 +01:00
|
|
|
$years = array_fuse($years);
|
2012-04-04 21:14:10 +02:00
|
|
|
|
|
|
|
$days_sel = AphrontFormSelectControl::renderSelectTag(
|
|
|
|
$this->getDayInputValue(),
|
|
|
|
$days,
|
|
|
|
array(
|
|
|
|
'name' => $this->getDayInputName(),
|
|
|
|
'sigil' => 'day-input',
|
|
|
|
));
|
|
|
|
|
|
|
|
$months_sel = AphrontFormSelectControl::renderSelectTag(
|
|
|
|
$this->getMonthInputValue(),
|
|
|
|
$months,
|
|
|
|
array(
|
|
|
|
'name' => $this->getMonthInputName(),
|
|
|
|
'sigil' => 'month-input',
|
|
|
|
));
|
|
|
|
|
|
|
|
$years_sel = AphrontFormSelectControl::renderSelectTag(
|
|
|
|
$this->getYearInputValue(),
|
|
|
|
$years,
|
|
|
|
array(
|
|
|
|
'name' => $this->getYearInputName(),
|
|
|
|
'sigil' => 'year-input',
|
|
|
|
));
|
|
|
|
|
2013-01-25 21:57:17 +01:00
|
|
|
$cal_icon = javelin_tag(
|
2012-04-04 21:14:10 +02:00
|
|
|
'a',
|
|
|
|
array(
|
|
|
|
'href' => '#',
|
|
|
|
'class' => 'calendar-button',
|
|
|
|
'sigil' => 'calendar-button',
|
|
|
|
),
|
|
|
|
'');
|
|
|
|
|
2013-01-18 03:57:09 +01:00
|
|
|
$time_sel = phutil_tag(
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
'input',
|
2012-04-04 21:14:10 +02:00
|
|
|
array(
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
'name' => $this->getTimeInputName(),
|
|
|
|
'sigil' => 'time-input',
|
|
|
|
'value' => $this->getTimeInputValue(),
|
|
|
|
'type' => 'text',
|
|
|
|
'class' => 'aphront-form-date-time-input',
|
|
|
|
),
|
|
|
|
'');
|
|
|
|
|
|
|
|
Javelin::initBehavior('fancy-datepicker', array());
|
2012-04-04 21:14:10 +02:00
|
|
|
|
2013-02-02 15:04:54 +01:00
|
|
|
return javelin_tag(
|
2012-04-04 21:14:10 +02:00
|
|
|
'div',
|
|
|
|
array(
|
|
|
|
'class' => 'aphront-form-date-container',
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
'sigil' => 'phabricator-date-control',
|
2012-04-04 21:14:10 +02:00
|
|
|
),
|
2013-02-02 15:04:54 +01:00
|
|
|
array(
|
|
|
|
$days_sel,
|
|
|
|
$months_sel,
|
|
|
|
$years_sel,
|
|
|
|
$cal_icon,
|
|
|
|
$time_sel,
|
|
|
|
));
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|