2025-12-04 nightly release (3cf501c)

Author: pytorchbot

.github/ISSUE_TEMPLATE/feature-request.yml

@@ -0,0 +1,27 @@
+name: ✨ Feature Request
+description: Suggest a new feature or enhancement for this project
+
+body:
+- type: markdown
+  attributes:
+    value: >
+      #### Before submitting a feature request, please search through [existing issues](https://github.com/meta-pytorch/forge/issues?q=is%3Aissue+sort%3Acreated-desc+) to see if something similar has already been proposed.
+- type: textarea
+  attributes:
+    label: Context/Motivation
+    description: |
+      Describe the problem you're trying to solve or the use case for this feature. Include any relevant links and context.
+  validations:
+    required: true
+- type: textarea
+  attributes:
+    label: Pseudo-code + acceptance criteria [Optional]
+    description: |
+      Provide a rough sketch of what the API or implementation might look like. This helps us understand your vision for how the feature would work.
+      Also, if possible, include what would need to be true for this feature to be considered complete.
+  validations:
+    required: false
+- type: markdown
+  attributes:
+    value: >
+      Thanks for contributing 🎉!

README.md

@@ -6,7 +6,7 @@
 [![Discord](https://img.shields.io/badge/Discord-OpenEnv-7289da?style=flat&logo=discord&logoColor=white)](https://discord.gg/YsTYBh6PD9)
 
 ## Overview
-The primary purpose of the torchforge ecosystem is to delineate infra concerns from model concerns thereby making RL experimentation easier. torchforge delivers this by providing clear RL abstractions and one scalable implementation of these abstractions. When you need fine-grained control over placement, fault handling/redirecting training loads during a run, or communication patterns, the primitives are there. When you don’t, you can focus purely on your RL algorithm.
+The primary purpose of the torchforge ecosystem is to separate infra concerns from model concerns thereby making RL experimentation easier. torchforge delivers this by providing clear RL abstractions and one scalable implementation of these abstractions. When you need fine-grained control over placement, fault handling/redirecting training loads during a run, or communication patterns, the primitives are there. When you don’t, you can focus purely on your RL algorithm.
 
 Key features:
 - Usability for rapid research (isolating the RL loop from infrastructure)

src/forge/observability/metrics.py

@@ -10,14 +10,12 @@
 import json
 import logging
 import os
+import time
 from abc import ABC, abstractmethod
 from dataclasses import dataclass
-from datetime import datetime
 from enum import Enum
 from typing import Any, Dict, List
 
-import pytz
-
 from forge.observability.utils import get_proc_name_with_rank
 
 from forge.util.logging import get_logger, log_once
@@ -91,7 +89,7 @@ def accumulator_class(self):
 class Metric:
     """Container for metric data including key, value, reduction type, and timestamp.
 
-    Timestamp is automatically set to current UTC time if not provided.
+    Timestamp is automatically set to current time if not provided.
     """
 
     key: str
@@ -101,8 +99,7 @@ class Metric:
 
     def __post_init__(self):
         if self.timestamp is None:
-            # Always record in UTC timezone
-            self.timestamp = datetime.now(pytz.UTC).timestamp()
+            self.timestamp = time.time()
 
 
 def record_metric(key: str, value: Any, reduction: Reduce = Reduce.MEAN) -> None: