Ева формат даты и времени для поля

Question

Python3.7 :: Eve :

Ищете способ форматирования даты и времени для поля домена вместо установки глобального формата даты и времени?

Я пытаюсь сохранить формат yyyy-mm-dd, но я не хочу менять работу _created и _update. Мне лучше просто хранить строку и обрабатывать преобразование даты как часть внешнего рендера?

- edit-- Было бы дорого использовать такой валидатор?

import datetime
from dateutil.parser import parse
from eve.io.mongo import Validator


class MyValidator(Validator):
    """
    Extend / override the built-in validation rules
    """
    def _validate_is_yyyymmdd(self, is_yyyymmdd, field, value):
        """datetime format yyyy-mm-dd"""
        print(is_yyyymmdd, field, value)
        print(datetime.datetime.strptime(value, r'%Y-%m-%d'))
        print(is_yyyymmdd and datetime.datetime.strptime(value, r'%Y-%m-%d'))
        try:
            if is_yyyymmdd and datetime.datetime.strptime(value, r'%Y-%m-%d'):
                return
        except:
            self._error(field, "Value is not valid yyyy-mm-dd")

volumes.py

volumes = {


'schema':{      
    'record_date':{
        'type':'string',
        'is_yyyymmdd':True,
        },             
    'volume_gallons':{'type':'float'},
}

решено - обновление

DATE_FORMAT = r"%Y-%m-%dT%H:%M:%S.%f%Z%z"

Используя новый формат даты, полезная нагрузка может быть передана с настройкой часового пояса, которая затем сохраняется в монго как UTC.

        {
        "record_date":"2019-04-06T15:49:12.012UTC+0500",                
        "group":"horizontal",
        "program_year":2016
        }

Python-скрипт для преобразования в utc с заданного времени

from datetime import datetime
from dateutil import tz
from dateutil.parser import parse


def main():
    """
    modified solution found here: /3559390/preobrazovat-stroku-daty-i-vremeni-utc-v-mestnuy-datu-i-vremya
    """


    # set the time zones to convert from and to
    # https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
    from_zone = tz.gettz('America/Denver')
    to_zone = tz.tzutc()


    # This is the format SQL Server outputs date time   
    datetime_str = "2019-03-21 02:37:21"

    # local = datetime.strptime(datetime_str, '%Y-%m-%d %H:%M:%S')
    local = parse(datetime_str)

    # Tell the datetime object that it's in local time zone since 
    # datetime objects are 'naive' by default
    local = local.replace(tzinfo=from_zone)

    # Convert time zone
    utc = local.astimezone(to_zone)
    print(utc, local)


if __name__ == "__main__":
    main()

Answer 1

Как правило, рекомендуется оставить поле базы данных в его наиболее независимом формате.

Создать метод для обработки деталей преобразования.

Если вас раздражает перспектива вводаИз полного преобразования даты / времени каждый раз, когда вам нужно получить дату, вы можете создать метод в вашем объекте, который будет обрабатывать преобразование так, как вам нравится.

Таким образом, вы можете назвать его как-нибудь легкозапомнить и избавить себя от необходимости запоминать точную запись функции формата даты / времени.

Вы можете даже создать суперкласс для своих объектов и добавить туда метод, чтобы он был унаследованвсеми объектами, для которых вы хотите, чтобы это поведение было доступно.

Так что, если у вас есть класс BlogObject в качестве суперкласса, а BlogPost наследует от BlogObject, и вы получаете доступ к стандартному полю, которое существует ввсе эти объекты, такие как Дата создания или Дата изменения

class BlogObject(BaseClassName):
    def pretty_create_dt():
        self.beatify_date(self.update_dt)

    def beautify_date(date):
        #[your format code]

#then have the other class(es) inherit the method:

class BlogPost(BlogObject):
    def get_xmas_date_before(days_before_xmas):
        date_x_before_christmas = self.beautify_date(self.xmas_dt - days_before_xmas)
        #pseudo-code-ish, just to get the point across

Таким образом, когда вы вызываете функцию дляВ вашем шаблоне он уже отформатирован моделью или контроллером.Вам следует избегать подобных действий в View, потому что это плохая практика MVC, особенно для того, что вы планируете использовать для всего приложения.

Причина, по которой этот общепринятый шаблон, заключается в том, что

1. уменьшает повторяющуюся обработку кода, которая подвержена человеческим ошибкам
2. менее трудоемка для будущего развития

3. поддерживает присущую принципу "разделение по дежурству"в MVC Framework

   Например, если политика формата даты должна была измениться, возможно, из-за интернационализации, то вам нужно решение, которое можно изменить в одном месте (суперкласс модели или контроллера), а нев 1000 экземпляров просмотра