Invalid posix timezone format

[Roland Bock <rbock@…>]

Hi,

I think that posix_time_zone in Boost.DateTime is using the wrong sign for offsets from GMT:

According to the documentation, posix_time_zone is modeled after IEEE Std 1003.1. The documentation gives several examples, for instance

"MST-7"

This zone is as simple as it gets. This zone lies seven hours west of GMT and has no daylight savings.

But all other sources for IEEE Std 1003.1 I found so far say that negative offsets indicate east of GMT, see for instance:

​http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

If preceded by a '-' , the timezone shall be east of the Prime Meridian; otherwise, it shall be west (which may be indicated by an optional preceding '+').

​http://tools.ietf.org/html/draft-ietf-dhc-timezone-01

The format of the IEEE 1003.1 POSIX timezone specification is defined as follows:[...]If preceded by a '-', the timezone is east of the Prime Meridian, otherwise it is west ('+' is optional)

​http://www.twinsun.com/tz/tz-link.htm

Numeric time zone abbreviations typically count hours east of UTC, e.g., +09 for Japan and -10 for Hawaii. However, the POSIX TZ environment variable uses the opposite convention. For example, one might use TZ="JST-9" and TZ="HST10" for Japan and Hawaii, respectively.

---

IMO, the implementation and/or the documentation should be changed. Personally, I'd prefer a change in the implementation, even though this would be a rather nasty breaking change.

Regards,

Roland

[fkonvick]

I was just about to post to boost-users on this (but then I found this ticket so I won't). My observation is the same. I was able to find the following discussion on the subject:

​http://lists.boost.org/boost-users/2006/10/23162.php

The problem I see is that the documentation says that the library follows the POSIX standard but it really doesn't. I also saw that some toolkits that use the Boost implementation claim the same thing, which IMHO causes a lot of existing and potential future confusion.

I think that either the docs should be fixed, or the code changed to respect the standard.

I'm changing the Version to 1.54 as is still exists there (I believe it also happens on the newer versions) and re-setting the Milestone to TBD (clearly 1.44 is not valid anymore).

[anonymous]

Just discovered the same thing today. We're using 1.61.

[anonymous]

Just discovered the same thing today. We're using 1.61.

[anonymous]

Just discovered the same thing today. We're using 1.61.