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
Static UTC offsets really aren't enough for lots of use cases due to DST and other timezone changes. In a lot of cases you really want to be storing "date + location", rather than "date + offset". So obviously all of this is useful.
That said, one of the downsides of adding this is that TOML will now rely on a timezone info database. A related issue is one of updates: "Europe/Narnia" could be created tomorrow; or the definition of a timezone can change. Often it will introduce an extra dependency in some form or the other that every TOML implementation and application using TOML will now need.
In addition, in the context of TOML, I think you probably don't need it that often. By and large, people aren't storing meeting times or user timezone preferences in TOML files. The entire datetime feature in general probably isn't very often used.
So on balance, I think it's probably best to leave time up to applications, because the downsides outweigh the upsides. For example as:
There is an update to RFC 3339, 9557. It allows not only for flat offsets, but also for specifying timezone information.
This should be added as an allowed timestamp format in the TOML spec.
The text was updated successfully, but these errors were encountered: