Could you add support to pass a parameter to return wind speed formatted as mph?
E.g:

Seems pretty cool, this can be shared in a more awesome way if the open graph and twitter cards meta tags are available here

Whether by visting http://wttr.in or entering curl wttr.in in a terminal the results are the same. A single word ERROR is displayed.

However, when wttr.in is fed parameters it seems to work fine.

Support ISO 8601 format for weather forecast for a specific location and date. (up to 7 days in the future)
e.g.
curl -s wttr.in/Chicago@2017-02-01

The return should be the weather forecast for that exact date.

If the date is beyond 7 days out, "invalid date" output should be returned.

References:
http://www.iso.org/iso/home/standards/iso8601.htm
https://en.wikipedia.org/wiki/ISO_8601

I wonder if you could add an option to specify the width of your terminal so that the tables are always pretty printed. Something like:

$ curl "wttr.in/?w=WIDTH"

This would make it possible to use tput cols or the COLUMNS environment variable to always have pretty printed tables!

With different WIDTHs we would have:

WIDTH >= 125:

                                                       ┌─────────────┐                                                       
┌──────────────────────────────┬───────────────────────┤ Wed 25. Jan ├───────────────────────┬──────────────────────────────┐
│           Morning            │             Noon      └──────┬──────┘    Evening            │            Night             │
├──────────────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┤
│     \   /     Sunny          │     \   /     Sunny          │               Cloudy         │      .-.      Light drizzle  │
│      .-.      10 – 11 °C     │      .-.      15 °C          │      .--.     11 – 12 °C     │     (   ).    10 – 12 °C     │
│   ― (   ) ―   ↖ 7 – 9 km/h   │   ― (   ) ―   ↑ 13 – 14 km/h │   .-(    ).   ↑ 14 – 22 km/h │    (___(__)   ↑ 15 – 24 km/h │
│      `-’      10 km          │      `-’      10 km          │  (___.__)__)  10 km          │     ‘ ‘ ‘ ‘   2 km           │
│     /   \     0.0 mm | 0%    │     /   \     0.0 mm | 0%    │               0.0 mm | 0%    │    ‘ ‘ ‘ ‘    0.5 mm | 95%   │
└──────────────────────────────┴──────────────────────────────┴──────────────────────────────┴──────────────────────────────┘

63 <= WIDTH < 125:

                        ┌─────────────┐
┌───────────────────────┤ Wed 25. Jan ├───────────────────────┐
│           Morning     └──────┬──────┘      Noon             │
├──────────────────────────────┼──────────────────────────────┤
│     \   /     Sunny          │     \   /     Sunny          │
│      .-.      10 – 11 °C     │      .-.      15 °C          │
│   ― (   ) ―   ↖ 7 – 9 km/h   │   ― (   ) ―   ↑ 13 – 14 km/h │
│      `-’      10 km          │      `-’      10 km          │
│     /   \     0.0 mm | 0%    │     /   \     0.0 mm | 0%    │
├──────────────────────────────┼──────────────────────────────┤
│           Evening            │            Night             │
├──────────────────────────────┼──────────────────────────────┤
│               Cloudy         │      .-.      Light drizzle  │
│      .--.     11 – 12 °C     │     (   ).    10 – 12 °C     │
│   .-(    ).   ↑ 14 – 22 km/h │    (___(__)   ↑ 15 – 24 km/h │
│  (___.__)__)  10 km          │     ‘ ‘ ‘ ‘   2 km           │
│               0.0 mm | 0%    │    ‘ ‘ ‘ ‘    0.5 mm | 95%   │
└──────────────────────────────┴──────────────────────────────┘

WIDTH < 63 (only looks good if WIDTH >= 32):

┌─────────────┐
│ Wed 25. Jan │
├─────────────┴────────────────┐
│           Morning            │
├──────────────────────────────┤
│     \   /     Sunny          │
│      .-.      10 – 11 °C     │
│   ― (   ) ―   ↖ 7 – 9 km/h   │
│      `-’      10 km          │
│     /   \     0.0 mm | 0%    │
├──────────────────────────────┤
│             Noon             │
├──────────────────────────────┤
│     \   /     Sunny          │
│      .-.      15 °C          │
│   ― (   ) ―   ↑ 13 – 14 km/h │
│      `-’      10 km          │
│     /   \     0.0 mm | 0%    │
├──────────────────────────────┤
│           Evening            │
├──────────────────────────────┤
│               Cloudy         │
│      .--.     11 – 12 °C     │
│   .-(    ).   ↑ 14 – 22 km/h │
│  (___.__)__)  10 km          │
│               0.0 mm | 0%    │
├──────────────────────────────┤
│            Night             │
├──────────────────────────────┤
│      .-.      Light drizzle  │
│     (   ).    10 – 12 °C     │
│    (___(__)   ↑ 15 – 24 km/h │
│     ‘ ‘ ‘ ‘   2 km           │
│    ‘ ‘ ‘ ‘    0.5 mm | 95%   │
└──────────────────────────────┘

Note: I aligned the date in this last example to the left, but maybe try something else! :-D

What are your thoughts on this?

While one of the features of wego is SSL, https://wttr.in is serving a self-signed certificate.

In the post Let's Encrypt worlds I do not really see why a self-signed certificate would be necessary.

If I can be of any help with regards to this, please do let me know.

The server always sends "Content-Type: text/html; charset=utf-8", even when the content clearly is not HTML. See curl -I wttr.in.

It works, but wouldn't it be nicer to send "text/plain" when it's just text, not HTML?

With the original backend making api's pay only I feel throwing the suggesting of implementing dark sky would be a good option.

The only thing that would be needed is to have it push coords instead of a city name, but will prove unreliable when it comes to accurate locations

It would be great if we could manually set the amount of forecast days the url-call delivers.

i.e. if i want to see just 1 day instead of 3 days

Might be related with #30

right now it shows me -9 – -3 °C

but it's +6 in reality

wttr.in shows no degrees centigrade in Opera version 36.0 browser, it shows only fahrenheit.

Suggestion: Why not use custom tags for the color, easier to write and read.
<c1b33> or <yellow>
The stylesheet will become more readable too:
yellow { color: yellow; }

No further styling or tricks would be needed and you don't have to set fonts, you can simply wrap it all in a <pre> tag.

Weather for City: Portola Valley, United States of America should probably be Weather for City: Portola Valley, CA, United States of America

Hi,
When I try to see Isfahan weather, the output return Afghanistan country instead of Iran.

hypermit@hp ~> curl wttr.in/isfahan
Weather for City: Isfahan, Afghanistan

           Blowing Widespread Dust
  .--.     10 – 13 °C     

.-( ). → 43 km/h
(.)_) 3 km
0.0 mm

Hi,

Is it possible to add the country next to the city so that the results come from the town that is present in that country?
For example, Carlisle is a town in USA and UK. But wttr.in/carlisle gives the results for Carlisle that is found in UK.

Sorry for filing a non-issue but I think it needs to be said, this application is amazing and you are amazing developers for sharing it with the world. I dream of a world wide web that is browsable from curl.

Thank you!

wttr.in page showing ERROR

It would be great to have options for shorter/longer output. Like:

$ curl 'http://wttr.in/?now'

               Overcast 
      .--.     64 °F          
   .-(    ).   ↑ 18 mph       
  (___.__)__)  9 mi           
               0.0 in   

Another one I would use is curl http://wttr.in/?week, where just a 5 day forecast it shown with only one row of output.

I'm sorry I don't have a pull request to go with this. I just wanted to put the idea out there.

curl wttr.in/nuremberg

504 Gateway Time-out

Examples:

(from issue #62):

when we do not pass any input to the url and it recognizes the location through ip address, the results are still from Carlisle, UK.

There are some other issues like that.

Hitting wttr.in from 50.150.86.x (Comcast) (Discovery Bay, Northern California) reports "Weather for City: Discovery Bay, Jamaica"

overview

When I access using browser, the layout is badly proportioned, like this capture.
(even pre tag and font-family:monospacehas been already enable.)

env

[OS] OS X Yosemite v10.10.2
[browser] Google Chrome v48

Hi, my location is identified as "Sevastopol, Russia" instead of Sevastopol, Ukraine.

Like a nearby town Simferopol, that identified correctly (Simferopol, Ukraine).

Thanks.

Hi, i love wttr.in and have been using it for a lot of personal projects lately. I believe wego supports JSON as an output (specified as a "frontend", though I haven't tested this personally). It would be awesome if wttr.in could support JSON output (or specifying any arbitrary frontend I suppose)... maybe something like:

• GET /Buffalo - buffalo ny weather
• GET /Buffalo?frontend=json - buffalo ny weather with -f json passed to the wego command

There might need to be some extra processing by wttr.in to specify the appropriate headers to the requesting client to let it know the response is JSON.

If there is interest in this I can take a look at the code and see what I can do

When I make a request for Sao Paulo city, it says the following:

$ curl wttr.in/Sao%20Paulo
  'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128)

But when I ask for Ribeirao Preto, it works:

curl wttr.in/Ribeirao%20Preto
Weather for City: Ribeirao Preto, Brazil

    \  /       Partly Cloudy
  _ /"".-.     23 – 25 °C
    \_(   ).   ↓ 19 km/h
    /(___(__)  10 km
               0.6 mm

At the moment, wttr.in/Moon show the Moon in the GMT+3 time.

Proposed changes:

1. Use GMT by default
2. Switch timezone using additional param:

http://wttr.in/Moon?TZ=EET

I've checked the docs and tried a few things but still get Celcius temperatures. Is there a flag to pass in the URL to switch to Fahrenheit?

The console is not able to display data returned by curl wttr.in. It's all garbled. I know it's a Windows problem but do you have any suggestions on how can I make it work.

I even tried an external console emulator, ConEmu. No luck there too.

I got "ERROR" in response when calling weather for Warsaw. Other cities works fine.

curl -i wttr.in/Warsaw                                                     
HTTP/1.1 200 OK
Server: nginx/1.9.14
Date: Wed, 12 Oct 2016 11:43:36 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 5
Connection: keep-alive

ERROR⏎  

Hello,

I really like the ascii weather and i typed "curl wttr.in" at terminal.

Unfortunately the output is;

Weather for City: Kartal, Hungary (I reside in Istanbul)

I know curl wttr.in/Istanbul returns the correct result but what is the reason for the hungary result?
First I think the reason arises from zenmate but they did not have correlation between them.

Title says it, and the code is all there.

Maybe set cookie later so further requests gets served with desired scheme.

I was playing around with curl before looking at the source code and this generates a 500 error: curl 'http://wttr.in/' -H 'User-Agent: '.

You may want to add an extra check or try block around https://github.com/chubin/wttr.in/blob/master/bin/srv.py#L225

Humidity level should show. Very useful since it affects a lot the confort level.

I got data for my city Skopje which is in the Republic of Macedonia but the website gives the text in Bulgarian.

Bulgarian and Macedonian may have the same roots but we have different letters and it's a different language and as younger people try to look at sites they don't understand Bulgarian.

You can add an option to choose the language it'd be really nice

and probably try translating it to Macedonian. If you need help DM me on Twitter or i'll submit them here

Love the service and the text weather!
Just found this project after installing LXLE.

I'm not sure what the datasource capacity is. Based on the error message on your webpage, it sounds like it could be 1M queries per day.

Doing some quick math, you can serve up

• 11 different locations once per second for 24 hours
• 57 different locations once per 5 seconds for 24 hours

I'd be curious to see the traffic log and see how many different locations are being served and at what rate. If a lot of traffic comes from a few locations, caching either using srv.py or at the client could help. Weather doesn't change by the second usually, so it might be useful to cache weather for between 5 seconds and 5 minutes to reduce the number of queries sent to your datasource.

I may try to implement something like that given some time free after my day job :)

First of all this is amazing! Thank you so much :)
I just thought it would be awesome to have tide levels showing as well, given their relation to the moon phases. Thanks again

Hello, i was looking into code and decided to perform some tests :)

Test command:
$ curl wttr.in/SomeVillage
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5 100 5 0 0 15 0 --:--:-- --:--:-- --:--:-- 15ERROR

Expected result:
It seems from code that in case of unknown location service should return following text:
"""
We were unable to find your location,
so we have brought you to Oymyakon,
one of the coldest permanently inhabited locales on the planet.
"""

Actual result:
$ curl wttr.in/SomeVillage
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5 100 5 0 0 15 0 --:--:-- --:--:-- --:--:-- 15ERROR

But I see weather report for Oymyakon if i type "$ curl wttr.in/NOT_FOUND"

Environment: Windows 10 x64, mintty 2.0.3 (x86_64-pc-msys)

If you are running into the 1M query limit, why not implement some sort of caching?

Maybe something like

weather = {
        {'city': 'Halifax', weather_info: ..., 'cached': datestamp}
        , ... 
        }

Only requery if the info is 30 minutes old - or even then are you seeing issues?

$ (0) curl wttr.in/@msu.ru
'tuple' object has no attribute 'lower'

Any chance of explicitly setting background color of output to dark background color? Visuals can be unreadable on light terminal themes.

Is it possible to add the Air Quality Index on wttr.in in the future?

I just get the following forecast:

                                                       ┌─────────────┐                                                       
┌──────────────────────────────┬───────────────────────┤ Wed 05. Oct ├───────────────────────┬──────────────────────────────┐
│           Morning            │             Noon      └──────┬──────┘    Evening            │            Night             │
├──────────────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┤
│      .-.      Light rain     │      .-.      Light drizzle  │  _`/"".-.     Patchy rain po…│     \   /     Clear          │
│     (   ).    15 °C          │     (   ).    17 °C          │   ,\_(   ).   18 °C          │      .-.      13 – 14 °C     │
│    (___(__)   ↗ 32 – 43 km/h │    (___(__)   ↑ 40 – 51 km/h │    /(___(__)  ↑ 26 – 37 km/h │   ― (   ) ―   ↑ 15 – 29 km/h │
│     ‘ ‘ ‘ ‘   9 km           │     ‘ ‘ ‘ ‘   2 km           │      ‘ ‘ ‘ ‘  9 km           │      `-’      10 km          │
│    ‘ ‘ ‘ ‘    0.8 mm | 84%   │    ‘ ‘ ‘ ‘    0.3 mm | 85%   │     ‘ ‘ ‘ ‘   0.2 mm | 71%   │     /   \     0.0 mm | 1%    │
└──────────────────────────────┴──────────────────────────────┴──────────────────────────────┴──────────────────────────────┘

If the night will be "clear", shouldn't it show a moon instead of a sun?

My location is identified as Oakville, United States of America instead of Oakville, Canada.

Is there any option to have all temps displayed in Fahrenheit, instead of Celsius? Or possibly added in the future?

Your example http config suggests you're listening externally on IPv6 and IPv4, but wttr.in only has an A record. I can only reach it from some of my machines.

sds@stkilda:~$ host -t aaaa wttr.in
wttr.in has no AAAA record
sds@stkilda:~$ host -t a wttr.in
wttr.in has address 5.9.243.177

When the min and max wind speeds are both 2 digits, the line formatting becomes pushed to the right and causes mismatched ASCII images.

Is it possible? Perharbs as auto detection/ "-locale_code" argument?

If weather server does not provide it, we can translate it manually I think.

How to change the timezone?

making donation through bountysource

thanks for correcting autolocation problems