Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

daylight savings support for WeeklySchedule #1904

Open
Mathadon opened this issue Jun 24, 2024 · 3 comments
Open

daylight savings support for WeeklySchedule #1904

Mathadon opened this issue Jun 24, 2024 · 3 comments

Comments

@Mathadon
Copy link
Member

For long simulations (longer than a few weeks), the local timezone may shift by one hour for daylight savings. We currently do not support that in the weekly schedule. Moreover, different regions perform the shift at different timestamps so we cannot hardcode the shift. My proposal would be to add optional support for this by adding a line in the config file like the two ones at the bottom:

# Comments start with a # 
mon:0:0:10          -  3   1  -
# Comments can be added in the table too 
tue,thu:20:30:59  123  -  45  -
wed                12  1   4  -
# users can set a timezone using a unix timestamp
1711877694         summertime
1730367294       wintertime

The switch would only work if the Modelica built in variable time is in the same range as the unix time stamp used since the weekly schedule does not know which year we are in.

Would it make sense to add this to IBPSA?

@mwetter
Copy link
Contributor

mwetter commented Jun 24, 2024

A couple of comment:

  • It is called daylight saving time rather than summertime, so I suggest to change the keyword
  • It would be better to start with the keyword as then, if other keywords are added, parsing should be easier if it is key word followed by (as set of) values, rather than the other way around
  • Why unix time stamp rather than seconds since Jan 1, and then assume has periodicity of 1 year. I don't think many users are familiar with/deal regularly with unix time stamps.
  • Are these entries optional?
  • Daylight savings time is usually starting at 2am. Will this also work if a schedule starts at 1:30, e.g., it will pass "1:30" twice, once before and once after the change?

@Mathadon
Copy link
Member Author

Thanks for the feedback:

  • Naming: The idea was to use 'wintertime' and 'summertime'. I'm not sure what the 'opposite' of 'daylightsavings' would be; 'nodaylightsavings'?
  • I think it would be better to start with the timestamp for all lines.
  • The number of seconds since January first would work too. I'd like to support both since we use time=unix time stamp.
  • The entries would indeed be optional.
  • The idea is that it should indeed pass 1:30 twice.

@mwetter
Copy link
Contributor

mwetter commented Jun 26, 2024

@Mathadon : If it is not daylight savings time, it is standard time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants