> "Dave" == Dave Rolsky <[EMAIL PROTECTED]> writes:
Dave> At the present time, all of these time zones follow the same rules, but
Dave> they did not do so in the past, and there's no guarantee that they will
Dave> in the future.
I've had a similar argument with international folks about how t
On Tue, 19 Aug 2008, Zefram wrote:
I can understand the arguments about EST, but if there's no ambiguity
about CET,
We just found an ambiguity about CET: does it include the DST rules?
Also, consider that your form of CET, with European-rules DST, is only
defined for 1977 and later (when the E
Ton Voon wrote:
>server's timezone to CET.
Dodgy concept there. It really doesn't make sense for a server as a
whole to have a default timezone other than UT. A timezone choice is
a feature of certain types of application data, not a feature of where
you run the application.
>I can understand t
On Mon, 18 Aug 2008, Eugene van der Pijll wrote:
Dave Rolsky schreef:
The problem is that CET could map to many, many different time zones
including Europe/Paris, Europe/Vienna, Europe/Tirane, and many more.
No, CET is unambiguously UTC +1, and therefore not equal to any of those
zones.
Tak
On 18 Aug 2008, at 17:25, Dave Rolsky wrote:
On Mon, 18 Aug 2008, Dave Rolsky wrote:
I guess I could add them back. Whatever this Solaris box returns
for CET comes from the Olson database, so the sysadmin shouldn't be
surprised by what DT::TZ does either.
I just committed a change to inc
Dave Rolsky schreef:
> The problem is that CET could map to many, many different time zones
> including Europe/Paris, Europe/Vienna, Europe/Tirane, and many more.
No, CET is unambiguously UTC +1, and therefore not equal to any of those
zones.
Eugene
On Mon, 18 Aug 2008, Dave Rolsky wrote:
I guess I could add them back. Whatever this Solaris box returns for CET
comes from the Olson database, so the sysadmin shouldn't be surprised by what
DT::TZ does either.
I just committed a change to include them. I realized that it's best if
the zones
On Mon, 18 Aug 2008, Ton Voon wrote:
I can understand the arguments about EST, but if there's no ambiguity about
CET, would it be correct to add that in? I note that EST, MST and HST are
supported timezones: http://search.cpan.org/dist/DateTime-TimeZone/.
If it is just a case of adding CET in
Ton Voon schreef:
> The user is a customer who is a sysadmin on Solaris. He's setting the
> server's timezone to CET.
Woudn't it be great if all servers were running (and all data was
stored) in UTC; an timezones were handled at the presentation level?
--
Affijn, Ruud
"Gewoon is een tijger."
2008/8/18 Ton Voon <[EMAIL PROTECTED]>:
> The user is a customer who is a sysadmin on Solaris. He's setting the
> server's timezone to CET. We have our catalyst application starting up with
> this default server timezone and it is failing because the CET timezone is
>
user is a customer who is a sysadmin on Solaris. He's setting the
server's timezone to CET. We have our catalyst application starting up
with this default server timezone and it is failing because the CET
timezone is not recognised in DateTime.
We don't present timezones to the
2008/8/18 Ton Voon <[EMAIL PROTECTED]>:
> I'm very naive in my understanding of best practices regarding timezones,
> but DateTime doesn't support the timezone CET. Is there a reason for it? Is
> it better to specify a timezone based on a location, such as Europe/Paris?
If you ever need to ask a u
Ton Voon wrote:
>timezones, but DateTime doesn't support the timezone CET. Is there a
>reason for it?
The lettered abbreviations for timezones are generally ambiguous.
Most famously, there's an "EST" in both America and Australia. I don't
think there's any "CET" other than Central European Time
Hi!
I'm very naive in my understanding of best practices regarding
timezones, but DateTime doesn't support the timezone CET. Is there a
reason for it? Is it better to specify a timezone based on a location,
such as Europe/Paris?
Ton
http://www.altinity.com
UK: +44 (0)870 787 9243
US: +1
14 matches
Mail list logo
