2

I need to parse many different dates in many different formats. I am having trouble with the following and wondered if anyopne could explain why;

The following works on a linux system:

from datetime import datetime
datetime.strptime('Tue 23 Aug 2011 09:00:07 PM BST','%a %d %b %Y %H:%M:%S %p %Z')

But running under windows it raises

ValueError: time data does not match format

However, if I try GMT not BST on windows, it works fine;

from datetime import datetime
datetime.strptime('Tue 23 Aug 2011 09:00:07 PM GMT','%a %d %b %Y %H:%M:%S %p %Z')

Is there a reason python does not understand the BST timezone under windows, but it works fine under Linux?

thanks,

Matt.

Matt Warren
  • 669
  • 8
  • 18
  • could `strptime` be implementation specific and the question isn't really about python, but about the c runtimes used by the interpreter? – Daren Thomas Aug 24 '11 at 15:15
  • I would say on top of that that your month has not to be in capital letters, try: **Aug** instead of AUG Do you really need the timezone %Z ? maybe you can do without it... –  Aug 24 '11 at 15:22
  • -daren something to look into.. thanks - -kingpin The capital AUG was an error, well spotted! I will edit the OP to correct it. – Matt Warren Aug 24 '11 at 15:43

1 Answers1

1

In my opinion, parsing a three-letter time zone code like this is not a good practice (unless of course you have no choice). For example, "EST" is commonly used in the USA for UTC-4/5 and is also commonly used in Australia. So any support for "EST" must therefore be dependent on locale. It would not surprise me if "BST" was similarly ambiguous.

I highly recommend using the pytz module in which British civil time is given the string identifier Europe/London and UTC is called Etc/UTC. The pytz API will give consistent results regardless of the locale of the user or system running the application.

If you are working on a UI that must be tied to locale, or parsing inputs with formats you cannot change, then consider using a dictionary of abbreviations to pytz timezone objects. For example: {'BST': 'Europe/London'}. Then your application can work with UTC dates and times uniformly, which will greatly reduce the possibility of errors.

wberry
  • 18,519
  • 8
  • 53
  • 85
  • 1
    I am parsing squillions of dates of many different formats and with various locales. pytz sounds interesting, I'll take a look. – Matt Warren Aug 24 '11 at 15:55
  • and you are right; BST is ambiguous, it is also 'Bangladesh Summer Time' !! – Matt Warren Aug 24 '11 at 15:56
  • 1
    Since you need to support multiple different locales, you may run into an "EST" situation, where two users expect the same exact input to have a different meaning. Beware and good luck. – wberry Aug 24 '11 at 15:59