jeff.gr...@kantarmedia.com 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: http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e Bob > ==================================================== > 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.
