#django

should datetimes coming out of my postgres database be in the local timzone? they seem to be in UTC

aidan, that depends on how your django project is configured.

TIME_ZONE = '...'

USE_TZ = True

if you want local time.

also, make sure you're not feeding django raw datetime objects

anyway: "Time zone support is disabled by default. "

dang`r`us: yeah I have a TIME_ZONE and USE_TZ set

aidan: pytz installed?

And yes, PG should have the UTC time stamps, iirc

aidan, 02:28:08 dang`r`us also, make sure you're not feeding django raw datetime objects

dang`r`us: created = models.DateTimeField(default=timezone.now, editable=False) ...

dang`r`us: def save(self, *args, **kwargs): self.updated = timezone.now()

aidan, looks a-ok

yeah :|

aidan, apparently the dates get normalized to UTC when saving, I'm observing the same thing here

In [13]: pytz.VERSION

Out[13]: '2015.4'

I just noticed our tests fail before 10am heh

ouch

heh... I remember a test that used to fail on weekends

Saving everything in UTC is about the only way to preserve your sanity.

yeah, after I thought a bit about it it totally makes sense

word

especially databases and users in different time zones

yeah, so saving in UTC makes sense ... I just thought they were meant to come out in the right timezone?

technically, you're losing detail by discarding the timezone of the original value entered... but it's not worth thinking about for 99.9999% of cases :)

What's the pattern to compare dates in tests then? timezone.make_aware(task.updated, timezone.get_current_timezone()).date() == date .. yuck

surely django does a SET TIMEZONE = settings.get('TIME_ZONE')

maybe Task.objects.get(pk=1).updated.astimezone(get_current_timezone()).date()

or we think in UTC in the backend until it's presentation time but that's yucky too with just dates.

why do you need non-utc dates anyway?

I mean

you can always convert them to your preferred time zone

dang`r`us: to eliminate ambiguity

aidan, ... say what now?

dang`r`us: our tests break at midnight because there's ambiguit

y

aidan, what kind of ambiguity are you talking about?

and how does that test case look

well, don't use timezone.now and instead get an UTC date

also, this test will always be a race condition around midnight

dang`r`us: we need some sort of internal policy on how we write code, at the moment it's obviously ambiguous.

it's not ambiguous, the test case is just dumb

let's say 'ambiguous' is a bad word. I'd choose 'brittle'.

why do you even test for date inequality like this?

The test makes sure rows get their updated value changed, to pick up on a bug caused by foo.otherobjects.all().update(x=y)

I could test for the exact datetime but also race conditions.

I'm debatig between postgresql vs mysql for django

aidan, get the objects, update them, get them again, test the updated time varies

or even "is larger"

toothe: pg

why?

Because postgres. :P

bc 1) mysql doesn't have transactions around ddl

2) because pg is smarter regarding indexing and query evaluation

3) ... (I'm too lazy to find the link(s) right now)

Heh. You can do a "?mysql" in #postgresql for some liks.

*links

But, unless you really want to get into the details, just save yourself the time and use Postgres.

Everything works better.

toothe: Coming from MySQL, PG feels a bit weird to administrate in the beginning but you get used to it pretty easily

MarkusH: yeah > seems reasonable

MarkusH: In what sense is it weird to administrate?

i've never admin'd a DB

yeah I learned all the tooling around mysql so pg was weird, but it's so much better

toothe: things like database templates

only one storage backend (who the f*** though MyISAM was a good idea in the first place??)

i think at some point I'm gonna have to dive into the differences between databases.

hey everyone, I am using django's send_email functionality

is it possible that when the SMTP server goes down it takes out the entire site?

No, it'd just raise an error.

got it, thanks matt

I've been browsing looking for an explanation, but is there some scenario where request.is_secure always returns True?

can it be related to the fact that I'm using nginx as a proxy?

when you tell django it's secure

where could I be doing that? if I'm using http only

well

it'

return self.scheme == 'https'

do you have SECURE_PROXY_SSL_HEADER set?

igh...it bothers me so much that my IPv6 address isn't automatically assigned...

yargh....

SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

and did you tell nginx to set that header?

if you're not using https... why did you set that setting?

IIRC there are big fuck-off warnings around using that

I think I left it when testing changing the site to https only

I am planning to change the whole site to https