0

I have flask webform that runs on gcloud, and I have noticed that when it runs the command

datetime.datetime.now()

I have different time depending if I run it as local server on my pc or through gcloud Does anyone know why (I am guessing is to do with the current timezone of the actual server, and how to tell gcloud my local time as opposed to theirs?

Thanks

FObersteiner
  • 22,500
  • 8
  • 42
  • 72
Lord_Amenegg
  • 59
  • 6
  • Let me save you years of future stress. Programmers worry about the time difference between this and that. Engineers think and design in GMT. – John Hanley Jul 21 '23 at 07:33
  • @JohnHanley British propaganda is what I say. – SomeSimpleton Jul 21 '23 at 07:36
  • @SomeSimpleton - Great response. How about a technical conversation about designing systems in local time versus GMT? Or is your preference UTC? Perhaps your preference is PST and suffer from Daylight Savings Time? Please recommend your solution regarding time. Your state propaganda? Hmm, perhaps I am uneducated, let me now the best solution. – John Hanley Jul 21 '23 at 07:47
  • @JohnHanley Touché. Twas some light hearted sarcasm but you had to go ahead and ruin it. – SomeSimpleton Jul 21 '23 at 07:52

1 Answers1

1

So yes it is to do with the server timezone. If you dont provide a timezone for datetime to work off of it will use your local timezone. You can provide a timezone to datetime for it return a time/date based off that timezone.

from datetime import datetime
import pytz

# Datetime using local system timezone
datetime.now()

# Datetime using specific timezone
datetime.now(pytz.timezone('US/Central'))

You can find all the pytz timezones available here. https://gist.github.com/heyalexej/8bf688fd67d7199be4a1682b3eec7568

SomeSimpleton
  • 350
  • 1
  • 2
  • 12
  • pytz is [deprecated](https://pypi.org/project/pytz-deprecation-shim/), please use [zoneinfo](https://docs.python.org/3/library/zoneinfo.html) – FObersteiner Jul 21 '23 at 09:51
  • Its not exactly quite deprecated. Update schedule is just slow so if your running on bleeding edge at all times probably not a good idea to use it but if your only going by stable builds and what not which some big corporations do you may still use it. – SomeSimpleton Jul 25 '23 at 00:41
  • Update schedule in this case means [tzdata](https://www.iana.org/time-zones) lags behind (pytz does not use the system tzdata as zoneinfo does on Unix systems), which means your datetimes can be wrong in certain time zones. That's not about "bleeding edge". So for this reason alone, I would not use and recommend it anymore, no matter how deprecated you consider it to be. If some big corp is slow to adopt new libraries, that should not mean you have to recommend what they're still using. – FObersteiner Jul 25 '23 at 05:29
  • see also [Is `pytz` deprecated now or in the future in Python?](https://stackoverflow.com/q/76583100/10197418) – FObersteiner Jul 25 '23 at 05:33