views:

228

answers:

2

I'm planning to write a sheduler app in python and I wouldn't be in trouble with DST and GMT handling.

As example see also PHP related question 563053.

Does anyone worked already on something similar?

Does anyone already experienced with PyTZ - Python Time Zone Library?

+3  A: 

Sure, many of us have worked on calendars / schedulers and are familiar with pytz. What's your specific question, that's not already well answered in the SO question you point to and ITS answers / comments...?

Edit: so there are no special, particular pitfalls if you do things as recommended in the best answers to the other question. In particular, do standardize on UTC internally ("GMT" is an antediluvian term and concept) and convert to/from timzones (w/DST &c) on I/O (just as you should standardize on Unicode internally and encode/decode to bytes, if you must, only on I/O!-).

There's a simple and flexible module in the Python standard library called sched which provides a configurable "event scheduler" and might be at the core of your app, with help from calendar, datetime etc. Some of the recipes in the "Time and Money" chapter of the Python Cookbook, 2nd ed, may help (it's widely available as online pirate copies, though as a co-author I don't necessarily LIKE that fact;-).

It's hard to say much more without having any idea of what you're writing -- web service, web app, desktop app, or whatever else. Do you want to support vCal, iCalendar, vCalendar, other forms of interop/sync/mashup and if so with what other apps, services and/or de facto standards? Etc, etc -- like all apps, it can grow and grow if it proves successful, of course;-).

Alex Martelli
Yeah! what I'm wondering is to know if there's some swamp to circumvent, in particular, before starting :-) and if there is a standard python module/library or pythonic way of solving a scheduler problem before reinvent the wheel. The problem is just implement a calendar/scheduler
DrFalk3n
+1: use UTC. There's no "swamp" -- that's why UTC was adopted for this kind of thing. Simply convert to local time for display purposes only -- to *all* the work in UTC.
S.Lott
ok so I don't expect to be in trouble following your suggestions tanks. Maybe you will know on SO if something goes bad :-)
DrFalk3n
@DrFalk3n, fingers crossed (of course I'd also expect to know by getting the answer accepted if everything goes just fine;-).
Alex Martelli
+1  A: 

pytz works great. Be sure to convert and store your times as UTC and use the pytz/datetime conversion routines to convert to local time. There's an example of usage and timezone conversion here, basically:

import datetime
import pytz
datetime.datetime(2008, 1, 31, 22, 56, 13, tzinfo=<UTC>)
utcdate.astimezone(pytz.timezone('US/Pacific'))
# result:    
# datetime.datetime(2008, 1, 31, 14, 56, 13, tzinfo=<DstTzInfo 'US/Pacific' PST-1 day, 16:00:00 STD>)
Parand
It's seems to be the "standard" way on planet hearth, I will follow and let you know. I repromize to accept your answer if everything goes...
DrFalk3n