As long as the calendar type isn’t `NOLEAP` it should rely completely on the `dateutil` library.
---
### Author:  [@holger](https://forum.access-hive.org.au/u/holger)
#### Post date: [13 July 2023 06:30 UTC](https://forum.access-hive.org.au/t/payu-potentially-miscalculating-a-leap-year/986/3 "2023-07-13T06:30:47Z")
It should. But it doesn’t.
I’ve tested it:
```python
from datetime import datetime
from dateutil.relativedelta import relativedelta
start = datetime(year=400, month=1, day=1)
end = start + relativedelta(years=1, months=0, days=0)
print(int((end-start).total_seconds())) # prints 31622400
```
But the namcouple file in the `work` directory the value is clearly set to 31536000
The first code snippet of your answer is surrounded by an `if` clause:
```python
if self.expt.runtime:
run_runtime = cal.runtime_from_date(
run_start_date,
self.expt.runtime['years'],
self.expt.runtime['months'],
self.expt.runtime['days'],
self.expt.runtime.get('seconds', 0),
caltype
)
else:
run_runtime = cpl_nml[cpl_group]['runtime']
```
I couldn’t figure out what `self.expt` is in this regard, or what `cpl_nml[cpl_group]['runtime']` is for that matter.
---
### Author:  [@dkhutch](https://forum.access-hive.org.au/u/dkhutch)
#### Post date: [14 March 2024 22:59 UTC](https://forum.access-hive.org.au/t/payu-potentially-miscalculating-a-leap-year/986/4 "2024-03-14T22:59:07Z")
Hi,
We have had a similar issue with @HIMADRI_SAINI when we get to year 1000 or year 400 of an ACCESS-ESM1.5 simulation. Did anything come of this discussion in terms of a payu or oasis fix?
More importantly, I was wondering if anyone could advise how to switch from Gregorian to NOLEAP calendar for ACCESS-ESM. @holger or @Scott ?
I’m pretty sure I know how the calendar is specified for the ocean, but not the other components.
Regards,
David
---
### Author:  [@Scott](https://forum.access-hive.org.au/u/Scott)
#### Post date: [14 March 2024 23:14 UTC](https://forum.access-hive.org.au/t/payu-potentially-miscalculating-a-leap-year/986/5 "2024-03-14T23:14:41Z")
Python’s datetime shouldn’t be trusted before the gregorian transition, try cftime instead.
UM calendar type will be somewhere in the namelists, for modern UM:
```ini
[namelist:nlstcall=lcal360]
compulsory=true
description=Use 360 day calendar
help=Climate users normally use a 360 day calendar to keep months and seasons a
=standard length. Others will use a normal Gregorian calendar to define the time
=information in model headers etc.
=
=The Gregorian calendar can be used with the coupled atmosphere-ocean
=climate model. When running the coupled model with the Gregorian calendar
=ancillaries created for the correct calendar must be used. If the
="Use 360 day calendar" option is not selected and the UM atmosphere
=is not running (i.e. NEMO,
=CICE,or NEMO-CICE runs),
=then the model
=will use a fixed 365-day calendar (no leap days).
ns=namelist/Top Level Model Control/Run Control and Time Settings
sort-key=4b
trigger=namelist:run_aerosol=l_temporal_emi: .false.
type=logical
warn-if=this==".true." and namelist:nlstcall=lclimrealyr==".true."
```
---
### Author:  [@dkhutch](https://forum.access-hive.org.au/u/dkhutch)
#### Post date: [15 March 2024 00:18 UTC](https://forum.access-hive.org.au/t/payu-potentially-miscalculating-a-leap-year/986/6 "2024-03-15T00:18:23Z")
Hi Scott,
In the **atmosphere/namelists** file, I can see the following:
```auto
LCLIMREALYR=.FALSE.,
LCAL360=.FALSE.,
LTIMER=.TRUE.,
L_IO_TIMER=.TRUE.,
TIME_CONVENTION='Absolute_standard',
```
The same lines also pop up in **CNTLALL** and **CONTCNTL**.
I would guess that **namelists** is the file that controls everything, but that is just a guess. (If so, why does it appear in the other 2?)
I don’t fully understand what all these options mean. **LCAL360** would seem to imply 30-day months, not sure about the other ones.
---
### Author:  [@Scott](https://forum.access-hive.org.au/u/Scott)
#### Post date: [15 March 2024 00:36 UTC](https://forum.access-hive.org.au/t/payu-potentially-miscalculating-a-leap-year/986/7 "2024-03-15T00:36:39Z")
See e.g. `/g/data/access/rose-meta/um/um-atmos/vn13.4/rose-meta.conf` for what namelist variables mean in the current UM. Yes LCAL360 is for a 360 day calendar, I don’t believe that the UM supports a 365 day calendar.
You are using a very old version of the UM before the namelist files were cleaned up and rationalised in version 10. Settings can be interdependent and appear in multiple locations as you see.
---
### Author:  [@dkhutch](https://forum.access-hive.org.au/u/dkhutch)
#### Post date: [15 March 2024 00:45 UTC](https://forum.access-hive.org.au/t/payu-potentially-miscalculating-a-leap-year/986/8 "2024-03-15T00:45:52Z")
Thanks for this. Well, if my only choices are 360 day years and Gregorian calendar, I think I will opt for the 360-day years. Others might stick with Gregorian if they have more simulations already advanced… I am early enough in mine that I could pull the plug and switch calendars.
---
### Author:  [@dkhutch](https://forum.access-hive.org.au/u/dkhutch)
#### Post date: [15 March 2024 03:10 UTC](https://forum.access-hive.org.au/t/payu-potentially-miscalculating-a-leap-year/986/9 "2024-03-15T03:10:20Z")
Update:
I just came across this utility:
```auto
/g/data/access/projects/access/apps/pythonlib/umfile_utils/change_dump_date.py
```
This gives a method of changing the date in a UM restart file. I think we might try and use this to reset the calendar and hopefully get over this issue with leap years not being in sync.
---
### Author:  [@Aidan](https://forum.access-hive.org.au/u/Aidan)
#### Post date: [15 March 2024 06:40 UTC](https://forum.access-hive.org.au/t/payu-potentially-miscalculating-a-leap-year/986/10 "2024-03-15T06:40:42Z")
Are these paleo simulations?
I ask because the Gregorian calendar implementation in MOM5 is bad. Super-bad.
They even say it isn’t supported
>
even though they have some code to handle Gregorian, it is buggy
>
Later versions of FMS, the library that provides this stuff has much improved Gregorian date handling
>
But that version of FMS isn’t compatible with MOM5.
And there are still some issues.
>
I don’t know why they wouldn’t just support Proleptic Gregorian, which is much simpler.