С этим кодом C:
int a = time(NULL);
_daylight = 0;
_timezone = 0;
int b = time(NULL);
assert(a != b);
«a» и «b» будут иметь разные значения (и не только потому, что они вызываются на расстоянии нескольких миллисекунд). Разница будет в том, что смещение часового пояса вашего компьютера будет от времени UTC. Кроме того, изменение значений _daylight и _timezone влияет практически на все остальные функции, которые я мог бы использовать в своем приложении C - я полагаю, потому что все они уважают это значение.
Есть ли что-нибудь подобное в Java или специально для Java в ОС Android? Я пробовал TimeZone.setDefault (), но это не изменило значение, которое вернул System.currentTimeMillis (), поэтому я предполагаю, что он не будет иметь «глобального» эффекта, как переменные Си.
Я понимаю, что System.currentTimeMillis () отличается от time () тем, что он «всегда» возвращает число миллисекунд с тех пор и до эпохи, а функция time () позволяет вам получить «false» (fudged) значения, которые корректируются в соответствии с этими глобальными переменными, которые вы можете установить.
Просто пытаюсь эмулировать устаревшее приложение C на ОС Android. Он очищает эти значения _timezone и _daylight, что в значительной степени означает, что он игнорирует любые часовые пояса. Поэтому, если пользователь, запустивший приложение на западном побережье, вводит время 15:00, а затем он меняет свои настройки часового пояса, или пользователь на восточном побережье просматривает этот элемент, он все равно будет отображаться как 15:00.
Я знаю, что могу использовать объект Calendar и другие методы, чтобы убедиться, что я делаю правильные преобразования, но я бы предпочел просто установить простые настройки "Мне все равно, часовые пояса", как в приложении C и тогда действительно не нужно беспокоиться о них.
Редактировать: Я все еще хотел бы услышать, какие у меня есть другие варианты, но сейчас я придумал этот Java-код, который я сделаю все возможное, чтобы всегда использовать его для любого кода, который должен имитировать приложение C:
// IMPORTANT: Use this function everywhere a Calendar object is needed, instead of calling
// Calendar.getInstance() directly. This returns the correct kludged time that matches
// what our PC application uses (_daylight=0, _timezone=0, time(NULL) in C)
public static Calendar GetCalendarInstance()
{
// Get the current UTC time
Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("UTC"));
// Offset it by the system time zone offset.
// This mimics what the C time(NULL) function does when you set _timezone=0 and _daylight=0
cal.add(Calendar.MILLISECOND, TimeZone.getDefault().getOffset(cal.getTimeInMillis()));
return(cal);
}
Кроме того, я уже нашел одно место в своем приложении для Android, в котором мне нужно реальное, а не скорректированное системное время (при использовании AlarmManager для планирования PendingIntent). Поэтому я думаю, что «глобальный» может быть опасным в любом случае. Я все еще думаю, что 95% моего кода будет использовать версию, которая имитирует приложение на C, поэтому, если возможно, я бы предпочел по умолчанию это, а затем должен был только выполнить специальную обработку для нескольких других мест.