[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: date does not recognise ULAT timezone to calculate UTC date

From: Bob Proulx
Subject: Re: date does not recognise ULAT timezone to calculate UTC date
Date: Wed, 19 Jun 2013 13:59:25 -0600
User-agent: Mutt/1.5.21 (2010-09-15)

address@hidden wrote:
> Running the command date on our server in Mongolia gives
>   $ date
>   Wed Jun 19 18:13:14 ULAT 2013
> However entering a date with the ULAT timezone to calculate the UTC
> date of an event in the past gives an error
>   $ date -u --date="25 May 2013 20:13 ULAT"
>   date: invalid date `25 May 2013 20:13 ULAT'

Using the "ULAT" locale specific name is the problem.  Using the short
locale specific abbreviations has always been problematic.  I am not
sure why the parser is getting confused by ULAT in this particular
case.  Perhaps someone else will look more deeply at it.

I always recommend using one of the standard formats such as
-R,--rfc-2822 format which is unambiguous.

  $ env TZ=Asia/Ulan_Bator date -R -d '25 May 2013 20:13'
  Sat, 25 May 2013 20:13:00 +0800

  $ date -u -d 'Sat, 25 May 2013 20:13:00 +0800'
  Sat May 25 12:13:00 UTC 2013

  $ date -R -u -d 'Sat, 25 May 2013 20:13:00 +0800'
  Sat, 25 May 2013 12:13:00 +0000

Using the RFC2822 format will yield more reliable results.

Of course you would like the locale specific timezone name to always
work for you.  But it can't.  Therefore the only answer I can offer is
to avoid the problem by avoiding using those names in date parsing
routines.  The date parser code is a best-effort attempt and makes
lots of mistakes.  Better to avoid tickling the problematic areas.

> Using the same format (ie taking the local timezone from a date
> command) works on our servers in other timezones such as CET, CEST,
> or SGT works perfectly.

Locale specific names are ambiguous and work some places and do not
work other places.  Since those are legacy there isn't anything that
can be done to improve it other than using an unambiguous format.

This problem is discussed in some detail in the FAQ:


> ====================================================
> This email is confidential and intended solely for the use of the
> individual or organization to whom it is addressed. Any opinions or
> advice presented are solely those of the author and do not necessarily
> represent those of the Kantar Media. If you are not the intended recipient
> of this email, you should not copy, modify, distribute or take any action
> in reliance on it. If you have received this email in error please notify
> the sender and delete this email from your system. Although this email
> has been checked for viruses and other defects, no responsibility can be
> accepted for any loss or damage arising from its receipt or use.
> ====================================================

READ CAREFULLY.  By reading this email, you agree, on behalf of your
employer, to release me from all obligations and waivers arising from
any and all NON-NEGOTIATED agreements, licences, terms-of-service,
shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure,
non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I
have entered into with your employer, its partners, licensors, agents
and assigns, in perpetuity, without prejudice to my ongoing rights and
privileges.  You further represent that you have the authority to
release me from any BOGUS AGREEMENTS on behalf of your employer.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]