Fix for changed default when reading in timezone naive data: we no lo…

…nger assume utc, but raise instead (since PR #521).

Fix tutorial timezone (#535)

* fix charging sensor name in tutorial

Signed-off-by: F.N. Claessen <felix@seita.nl>

* Fix for changed default when reading in timezone naive data: we no longer assume utc, but raise instead (see PR #521)

Signed-off-by: F.N. Claessen <felix@seita.nl>

Signed-off-by: F.N. Claessen <felix@seita.nl>

documentation/tut/toy-example-from-scratch.rst

@@ -108,7 +108,7 @@ FlexMeasures offers a command to create a toy account with a battery:
     $ flexmeasures add toy-account --kind battery
 
     Toy account Toy Account with user toy-user@flexmeasures.io created successfully. You might want to run `flexmeasures show account --id 1`
-    The sensor for battery charging is <Sensor 2: charging, unit: MW res.: 0:15:00>.
+    The sensor for battery (dis)charging is <Sensor 2: discharging, unit: MW res.: 0:15:00>.
     The sensor for Day ahead prices is <Sensor 3: Day ahead prices, unit: EUR/MWh res.: 1:00:00>.
 
 And with that, we're done with the structural data for this tutorial! 
@@ -211,12 +211,12 @@ This is time series data, in FlexMeasures we call "beliefs". Beliefs can also be
 
 .. code-block:: console
 
-    $ flexmeasures add beliefs --sensor-id 3 --source toy-user prices-tomorrow.csv
+    $ flexmeasures add beliefs --sensor-id 3 --source toy-user prices-tomorrow.csv --timezone utc
     Successfully created beliefs
 
 In FlexMeasures, all beliefs have a data source. Here, we use the username of the user we created earlier. We could also pass a user ID, or the name of a new data source we want to use for CLI scripts.
 
-.. note:: Attention: We created and imported prices where the times have no time zone component! That happens a lot. FlexMeasures will then interpret them as UTC time. So if you are in Amsterdam time, the start time for the first price, when expressed in your time zone, is actually `2022-03-03 01:00:00+01:00`.
+.. note:: Attention: We created and imported prices where the times have no time zone component! That happens a lot. Here, we localized the data to UTC time. So if you are in Amsterdam time, the start time for the first price, when expressed in your time zone, is actually `2022-03-03 01:00:00+01:00`.
 
 Let's look at the price data we just loaded:
 
@@ -278,7 +278,7 @@ Great. Let's see what we made:
 .. code-block:: console
 
     $ flexmeasures show beliefs --sensor-id 2 --start ${TOMORROW}T07:00:00+01:00 --duration PT12H
-    Beliefs for Sensor 'charging' (Id 2).
+    Beliefs for Sensor 'discharging' (Id 2).
     Data spans 12 hours and starts at 2022-03-04 07:00:00+01:00.
     The time resolution (x-axis) is 15 minutes.
     ┌────────────────────────────────────────────────────────────┐
@@ -301,7 +301,7 @@ Great. Let's see what we made:
     │                    ▙▄▄▌                ▐▄▄▞                │ 
     └────────────────────────────────────────────────────────────┘
             10           20           30          40
-                            ██ charging
+                            ██ discharging
 
 
 Here, negative values denote output from the grid, so that's when the battery gets charged. 

flexmeasures/cli/data_add.py

@@ -1110,7 +1110,7 @@ def add_toy_account(kind: str, name: str):
     click.echo(
         f"Toy account {name} with user {user.email} created successfully. You might want to run `flexmeasures show account --id {user.account.id}`"
     )
-    click.echo(f"The sensor for battery charging is {charging_sensor}.")
+    click.echo(f"The sensor for battery discharging is {charging_sensor}.")
     click.echo(f"The sensor for Day ahead prices is {day_ahead_sensor}.")