You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When 'CEST' or 'CET' time zone name is used in parsed string it is treated as UTC.
It should either be properly interpreted as Central European (Summer) Time, or an error should be reported or, at least, it should be treated as no time zone provided (so the default from parse_with_timezone() can be used). Current behaviour is quite unexpected.
Test code:
use chrono::Local;use dateparser::{parse, parse_with_timezone};pubfnmain(){check_date("2024-07-29 12:00:00 +02:00");check_date("2024-07-29 12:00:00 CEST");check_date("2024-07-29 12:00:00 CET");check_date("2024-07-29 12:00:00 PST");check_local_date("2024-07-29 12:00:00");check_local_date("2024-07-29 12:00:00 +02:00");check_local_date("2024-07-29 12:00:00 CEST");}fncheck_date(value:&str){println!("'{}' is: {}", value, parse(value).unwrap())}fncheck_local_date(value:&str){println!("'{}' is: {} (with local timezone)",
value,
parse_with_timezone(value,&Local).unwrap())}
Output:
'2024-07-29 12:00:00 +02:00' is: 2024-07-29 10:00:00 UTC
'2024-07-29 12:00:00 CEST' is: 2024-07-29 12:00:00 UTC
'2024-07-29 12:00:00 CET' is: 2024-07-29 12:00:00 UTC
'2024-07-29 12:00:00 PST' is: 2024-07-29 20:00:00 UTC
'2024-07-29 12:00:00' is: 2024-07-29 10:00:00 UTC (with local timezone)
'2024-07-29 12:00:00 +02:00' is: 2024-07-29 10:00:00 UTC (with local timezone)
'2024-07-29 12:00:00 CEST' is: 2024-07-29 12:00:00 UTC (with local timezone)
The string is properly interpreted by the date command:
$ date --date="2024-07-29 12:00:00 CEST"
Mon 29 Jul 12:00:00 CEST 2024
The text was updated successfully, but these errors were encountered:
When 'CEST' or 'CET' time zone name is used in parsed string it is treated as UTC.
It should either be properly interpreted as Central European (Summer) Time, or an error should be reported or, at least, it should be treated as no time zone provided (so the default from
parse_with_timezone()
can be used). Current behaviour is quite unexpected.Test code:
Output:
The string is properly interpreted by the
date
command:The text was updated successfully, but these errors were encountered: