dify 获取当前时间小工具希望可以支持时间格式的更改，否则知识库写入报错400

Self Checks

[X] This is only for bug report, if you would like to ask a quesion, please head to Discussions.
[X] I have searched for existing issues search for existing issues, including closed ones.
[X] I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
[X] Pleas do not modify this template :) and fill in all the required fields.

Dify version

0.6.5

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

我使用此格式：2024-05-05 11:30:08 CST 发送post请求至知识库API，报400错误。

"status_code": 400, "body": "{"code": "bad_request", "message": "The browser (or proxy) sent a request that this server could not understand.", "status": 400}\n",

如果是 2024年5月4日11时30分，将成功"status_code": 200,

✔️ Expected Behavior

"status_code": 200,

❌ Actual Behavior

"status_code": 400,

May 05 '24 03:05 zswll2

The issue you're encountering with the "2024-05-05 11:30:08 CST" time format leading to a 400 error is likely due to the server not recognizing this specific format. In Dify version 0.6.5, the current_time.yaml configuration does not include an option to specify custom time formats, which suggests that the server has predefined formats it can parse, and "2024-05-05 11:30:08 CST" is not one of them.

The successful parsing of "2024年5月4日11时30分" indicates that the server can understand this format, but without explicit support for custom time formats in Dify's configuration, you're limited to the formats the server inherently understands.

To address this, you might consider adjusting your time format to match the server's expectations, which could involve omitting the timezone or using a different format altogether. Unfortunately, without specific documentation on the server's accepted time formats or an update to Dify that allows for custom time format specification, a precise solution involves trial and error with different time formats or reaching out to the Dify maintainers for further guidance on supported time formats.

Details

Sources

About Dosu This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

To continue the conversation, mention @dosu.

May 05 '24 04:05 dosubot[bot]

Thank you for your answer. Actually, I am using the API of the knowledge base to write this time to record the time of the data. Currently, I can only use LLM to convert the time to Chinese description, so that I can successfully post it to the knowledge base. Although this method can be successful, I don't think it's necessary to use LLm for this small issue

------------------ 原始邮件 ------------------ 发件人: dosubot[bot] @.> 发送时间: 2024年5月5日 12:03 收件人: langgenius/dify @.> 抄送: zswll2 @.>, Author @.> 主题: Re: [langgenius/dify] 获取当前时间小工具希望可以支持时间格式的更改，否则知识库写入报错400 (Issue #4091)

The issue you're encountering with the "2024-05-05 11:30:08 CST" time format leading to a 400 error is likely due to the server not recognizing this specific format. In Dify version 0.6.5, the current_time.yaml configuration does not include an option to specify custom time formats, which suggests that the server has predefined formats it can parse, and "2024-05-05 11:30:08 CST" is not one of them.

The successful parsing of "2024年5月4日11时30分" indicates that the server can understand this format, but without explicit support for custom time formats in Dify's configuration, you're limited to the formats the server inherently understands.

To address this, you might consider adjusting your time format to match the server's expectations, which could involve omitting the timezone or using a different format altogether. Unfortunately, without specific documentation on the server's accepted time formats or an update to Dify that allows for custom time format specification, a precise solution involves trial and error with different time formats or reaching out to the Dify maintainers for further guidance on supported time formats.

Details

Sources

api/core/tools/provider/builtin/time/tools/current_time.yaml

en/community/contributing.md

About Dosu This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

To continue the conversation, mention @dosu.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

May 05 '24 04:05 zswll2

I understand your concern about not wanting to rely on LLM for converting time formats just to make successful API requests. Since the current setup requires a specific time format that the server can understand, and using LLM for conversion seems like an unnecessary step for such a task, I recommend exploring a more direct solution.

One approach could be to implement a simple conversion function in your code that formats the datetime string into an acceptable format before sending it to the knowledge base API. This function could take the datetime in any input format and convert it to the "2024年5月4日11时30分" format or any other format that you've confirmed works with the API.

Here's a basic outline of what such a function could look like in Python, for example:

from datetime import datetime

def convert_datetime_for_api(input_datetime_str):
    # Assuming 'input_datetime_str' is in the format '2024-05-05 11:30:08 CST'
    # Convert it to a datetime object
    dt_obj = datetime.strptime(input_datetime_str, '%Y-%m-%d %H:%M:%S %Z')
    
    # Format the datetime object to the desired format
    output_format = dt_obj.strftime('%Y年%m月%d日%H时%M分')
    
    return output_format

# Example usage
input_datetime_str = '2024-05-05 11:30:08 CST'
converted_datetime = convert_datetime_for_api(input_datetime_str)
print(converted_datetime)

This is just a starting point, and you might need to adjust the parsing and formatting strings according to your exact requirements. Also, consider handling time zones appropriately if they play a crucial role in your application.

By integrating such a conversion directly into your workflow, you can bypass the need for external tools like LLM for this purpose, streamlining the process and potentially reducing the complexity of your codebase.

Details

About Dosu This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

To continue the conversation, mention @dosu.

May 05 '24 04:05 dosubot[bot]

In fact, I have tried this method before, but it will prompt "not allowed operation". I think most of the functions executed by py are restricted, and py can only run the code examples explained in the API documentation

------------------ 原始邮件 ------------------ 发件人: dosubot[bot] @.> 发送时间: 2024年5月5日 12:26 收件人: langgenius/dify @.> 抄送: zswll2 @.>, Author @.> 主题: Re: [langgenius/dify] 获取当前时间小工具希望可以支持时间格式的更改，否则知识库写入报错400 (Issue #4091)

I understand your concern about not wanting to rely on LLM for converting time formats just to make successful API requests. Since the current setup requires a specific time format that the server can understand, and using LLM for conversion seems like an unnecessary step for such a task, I recommend exploring a more direct solution.

One approach could be to implement a simple conversion function in your code that formats the datetime string into an acceptable format before sending it to the knowledge base API. This function could take the datetime in any input format and convert it to the "2024年5月4日11时30分" format or any other format that you've confirmed works with the API.

Here's a basic outline of what such a function could look like in Python, for example: from datetime import datetime def convert_datetime_for_api(input_datetime_str): # Assuming 'input_datetime_str' is in the format '2024-05-05 11:30:08 CST' # Convert it to a datetime object dt_obj = datetime.strptime(input_datetime_str, '%Y-%m-%d %H:%M:%S %Z') # Format the datetime object to the desired format output_format = dt_obj.strftime('%Y年%m月%d日%H时%M分') return output_format # Example usage input_datetime_str = '2024-05-05 11:30:08 CST' converted_datetime = convert_datetime_for_api(input_datetime_str) print(converted_datetime)

This is just a starting point, and you might need to adjust the parsing and formatting strings according to your exact requirements. Also, consider handling time zones appropriately if they play a crucial role in your application.

By integrating such a conversion directly into your workflow, you can bypass the need for external tools like LLM for this purpose, streamlining the process and potentially reducing the complexity of your codebase.

Details

About Dosu This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

To continue the conversation, mention @dosu.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

May 05 '24 05:05 zswll2

It appears the issue with the datetime format and the "not allowed operation" error you're encountering is due to the specific requirements and restrictions of the Dify version 0.6.5. The knowledge base API expects datetime strings in a specific format, and the execution environment for Python code has limitations that prevent certain operations, particularly those involving network/IO actions.

To address the datetime format issue, ensure your datetime string is converted to a format that the API expects. Since direct manipulation of datetime formats using Python might be restricted, consider pre-formatting your datetime strings within the constraints provided by Dify's documentation.

Regarding the "not allowed operation" error, this is likely because Dify restricts Python code execution to native packages only, with network/IO operations disabled for security reasons. Ensure that your Python code adheres to these restrictions by avoiding network requests or direct file I/O operations.

For the timezone issue, "CST" might not be recognized by the API. Instead, use one of the supported timezone formats listed in Dify's documentation, such as "UTC" or a city-based timezone like "America/Chicago".

If you're still facing issues, ensure that your adjustments are within the allowed operations of Dify's simple_code tool and consider consulting the documentation for any updates or additional guidelines on executing Python code and formatting datetime strings.

Details

Sources

About Dosu This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

To continue the conversation, mention @dosu.

May 05 '24 05:05 dosubot[bot]

I suggest using a code node after the time node and reparse the format as you want for now, but this requirement sounds reasonable and I will put it into my plan, maybe take it done in few days!

May 05 '24 07:05 Yeuoly

I suggest using a code node after the time node and reparse the format as you want for now, but this requirement sounds reasonable and I will put it into my plan, maybe take it done in few days!

Yes, I have tried this operation, but the code does not work. Thank you for paying attention to this issue.

May 05 '24 14:05 zswll2