1. Java / Говнокод #8302

    +78

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    public Date localTimeToUTC(final Date localTime) {
    	final DateFormat format = DateFormat.getDateTimeInstance();
    	format.setTimeZone(UTC);
    	
    	// This is a bit of a trick. Since Java assumes dates are in UTC,
    	// but localTime is not (blame the weird legacy database...),
    	// it's a semantically incorrect Date. Therefore we process it as
    	// if it's in UTC...
    	final String formatted = format.format(localTime);
    	
    	format.setTimeZone(localTimeZone);
    	
    	try {
    		return format.parse(formatted);
    	} catch (final ParseException e) {
    		throw new AssertionError(e); // cannot happen
    	}
    }

    И вновь издержки обратной совместимости. Китайские кулибины хранили DateTime в старой базе в локальном часовом поясе.

    Запостил: lucidfox, 26 Октября 2011

    Комментарии (7) RSS

    • > хранили DateTime в старой базе в локальном часовом поясе
      разумеется, ведь Китай - Поднебесная, Центр Мира
      Ответить
      • Вот только часовой пояс был сиднейский, потому что там сервер.
        Ответить
        • а исполнить один запрос к базе не судьба?
          Ответить
          • Нельзя. С ней ещё работает старое приложение. Вот выбросят его вместе со старой базой - тогда пожалуйста. (И всё равно одним запросом не получилось бы, ибо летнее время.)
            Ответить
            • > ибо летнее время
              Это зависит. Oracle справилось бы, например. А то можно представление с вычисляемой колонкой создать и пусть старый говнокод наслаждается локальным временем
              Ответить
    • показать все, что скрытоvanished
      Ответить

    Добавить комментарий