datetime question

[Ferrous Cranus]

Στις 12/11/2013 4:03 μμ, ο/η Joel Goldstick έγÏαψε:

I think that is a great solution. What would happen if you just did this:
lastvisit2 = (datetime.now()).strftime('%y-%m-%d %H:%M:%S' )

Why don't you try it out and see what you find?

(PS, this was pointed out to me by a pro, so I did a little reading in
the python docs and took Andy's excellent code and added a couple of
lines to test.)

I switched to my local timezone "US/Eastern" to test. My machine is
running Ubuntu. It seems to know that it is in the Eastern US. If
your server knows where it lives, then this should work for you also.
If it is set to a different timezone, I'm not sure I could help you,
but I'm sure someone could. You even might ask your host if this is
possible.

----------------------
#! /usr/bin/env python

from datetime import datetime, time, timedelta
import time
import pytz

def is_dst(zonename):
tz = pytz.timezone(zonename)
now = pytz.utc.localize(datetime.utcnow())
return now.astimezone(tz).dst() != timedelta(0)

def dst_greece():
#if is_dst("Europe/Kiev") :
if is_dst("US/Eastern") :
diff = -6
else:
diff = -5
return diff

lastvisit = (datetime.utcnow()
+timedelta(hours=dst_greece())).strftime('%y-%m-%d %H:%M:%S' )

lastvisit2 = (datetime.now()).strftime('%y-%m-%d %H:%M:%S' )

print lastvisit
print lastvisit2

Joel i must thank you for your help.

I cannot believe it was so simple.

lastvisit = ( datetime.now() ).strftime('%y-%m-%d %H:%M:%S') # MySQL
datetime format


Tnhe server is self aware of its location so why use utcnow() +
timedelte( some_digit_here ) when you can just use just now()

Great solution, no need for function declaration and importing of new
pytz modules.

Simple and straightforward, Thank you!

 

[Roy Smith]

Don't forget that there are also some differences between American and
Imperial whitespace. Since it's ASCII whitespace, you should probably
assume American...

And don't assume that the whitespace you find in a red state is the same
as you'll find in a blue state.

 

[Chris Angelico]

Joel i must thank you for your help.

I cannot believe it was so simple.

Tnhe server is self aware of its location so why use utcnow() + timedelte(
some_digit_here ) when you can just use just now()

Did you ever go and look at the docs, like you were advised to?

Next time you have a problem, go read the docs. You never know, you
might discover something!

ChrisA

 

[Ferrous Cranus]

Στις 12/11/2013 4:57 μμ, ο/η Chris Angelico έγÏαψε:

Did you ever go and look at the docs, like you were advised to?

Next time you have a problem, go read the docs. You never know, you
might discover something!

ChrisA

But what of the server was in California and i live in Greece?

How would datetime.now() work then?

now() would return the time fo the server not my local time, so if i
change servers and the server isn't located to the same timezone as i'am
locally, wouldn't that raise a problem?

 

[Tim Chase]

But what of the server was in California and i live in Greece?

How would datetime.now() work then?

Best practices say to move the value from local time to UTC as soon
as possible, then store/use the UTC time internally for all
operations. Only when it's about to be presented to the user should
you convert it back to local time if you need to.

-tkc

 

[Ferrous Cranus]

Στις 12/11/2013 5:54 μμ, ο/η Tim Chase έγÏαψε:

Best practices say to move the value from local time to UTC as soon
as possible, then store/use the UTC time internally for all
operations. Only when it's about to be presented to the user should
you convert it back to local time if you need to.

-tkc

or perhaps by confiruing the timezone of the server to use Greece's
TimeZone by issuing a linux command?

 

[Tim Chase]

or perhaps by confiruing the timezone of the server to use Greece's
TimeZone by issuing a linux command?

Regardless of the server's configured TZ, best practice still says to
normalize everything to UTC (ESPECIALLY if Greece uses the
abomination of DST that we suffer here in the US) as soon as
possible and keep it that way for as long as possible.

-tkc

 

[MRAB]

Regardless of the server's configured TZ, best practice still says to
normalize everything to UTC (ESPECIALLY if Greece uses the
abomination of DST that we suffer here in the US) as soon as
possible and keep it that way for as long as possible.

FTR, the countries in the EU all change at the same (UTC) time.

 

[Joel Goldstick]

FTR, the countries in the EU all change at the same (UTC) time.

In the US, the state of Indiana is really weird. Three separate time
zone areas, that don't all flip in the same way. See this for TZ
hell: http://en.wikipedia.org/wiki/Indiana_time_zones

 

[Denis McMahon]

(I think "Europe/Kiev" is Greece but I don't know)

I suspect Nick is really in a coding sweatshop in "Asia/Mumbai"

 

[Denis McMahon]

or perhaps by confiruing the timezone of the server to use Greece's
TimeZone by issuing a linux command?

If you have that degreee of control over the server, yes, but UTC is
always safer, because if you need to move your server to a different site
(eg disaster recovery) UTC is still UTC.

 

[Chris Angelico]

In the US, the state of Indiana is really weird. Three separate time
zone areas, that don't all flip in the same way. See this for TZ
hell: http://en.wikipedia.org/wiki/Indiana_time_zones

Timezones are one of the most interesting [1] things in the world.
Ireland doesn't move clocks forward for summer time, they move them
backward for winter time... I swear, when I first heard that, I
thought it was just one of those Irish jokes with no basis, but it is
true...

https://en.wikipedia.org/wiki/Time_in_the_Republic_of_Ireland

Plus, they switch clocks at 2am all the time, not at 2am forward and
3am backward.

ChrisA

[1] Define "interesting".
http://www.imdb.com/title/tt0379786/quotes?item=qt0433039

 

[Dennis Lee Bieber]

Heh. Mine doesn't, so I bought myself a second watch and set it to
UTC. So my left hand has local time (changes at DST breaks, changes
when I travel internationally), and my right hand has UTC (never
changes).

http://www.amazon.com/Citizen-JY0000-53E-Skyhawk-Eco-Drive-Watch/dp/B000ZPMYQI

Only watch I've ever heard of having a recall... The radio synch logic
fell apart a few years back, and lost a day. As a result mine now has a
mark from a small center punch on the back to identify it as having had its
firmware redone.

I recall the sales lady's blunder... After persuading me on this model
(it was replacing an earlier Citizen Navi-Hawk as I recall) she tried to
sell me a battery replacement service plan -- for a watch that charges via
solar panel!

 

[Dennis Lee Bieber]

Plus, they switch clocks at 2am all the time, not at 2am forward and
3am backward.

2AM is the time at which US switches occur also, in either direction.

Unfortunately, my radio controlled clocks tend to synchronize between 1
and 2 AM, and those that automatically do daylight vs normal switching
(three Oregon Scientific) miss the broadcast of the change. My watch and a
LaCrosse unit require manual toggling between the two.


Good thing I don't run a store... I'd annoy my customers by changing
the store hours instead <G>

 

[Dennis Lee Bieber]

If you have that degreee of control over the server, yes, but UTC is
always safer, because if you need to move your server to a different site
(eg disaster recovery) UTC is still UTC.

And you don't have to run a batch job on your database to change
timestamps relative to the server local time.

 

[Chris Angelico]

http://www.amazon.com/Citizen-JY0000-53E-Skyhawk-Eco-Drive-Watch/dp/B000ZPMYQI

Only watch I've ever heard of having a recall... The radio synch logic
fell apart a few years back, and lost a day. As a result mine now has a
mark from a small center punch on the back to identify it as having had its
firmware redone.

I recall the sales lady's blunder... After persuading me on this model
(it was replacing an earlier Citizen Navi-Hawk as I recall) she tried to
sell me a battery replacement service plan -- for a watch that charges via
solar panel!

My UTC watch is an Eco-Drive too, but without radio sync, and much
simpler all round than yours. And roughly half the price, and that
counting the Amazon price not the list price. I don't think I could
justify to myself spending $650 on a second watch!!

If only more people would start "thinking UTC", all sorts of
synchronization problems would vanish.

ChrisA

 

[Roy Smith]

Best practices say to move the value from local time to UTC as soon as
possible, then store/use the UTC time internally for all operations.
Only when it's about to be presented to the user should you convert it
back to local time if you need to.

-tkc

& it is probably best converted to local time client side (as has already
been suggested) you may end up with a situation where the server is in
the USA & your user is in Portugal.[/QUOTE]

Or, your server is in California, your user is in Portugal, and he
prefers to keep his laptop on New York time.

 

[MRAB]

2AM is the time at which US switches occur also, in either direction.

The difference compared with the EU is that they switch according to
local time, so different US time zones switch at different UTC times.