# main.dart
import 'package:flutter/material.dart';
import 'package:flutter_app_stable/routes.dart';
import 'package:go_router/go_router.dart';
void main() {
  runApp(const MyApp());
final router = GoRouter(routes: $appRoutes);
class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);
  @override
  Widget build(BuildContext context) {
    return MaterialApp.router(
      routerConfig: router,
# routes.dart
import 'package:flutter/material.dart';
import 'package:go_router/go_router.dart';
part 'routes.g.dart';
@TypedGoRoute<HomeRoute>(
  path: '/',
  routes: [
    TypedGoRoute<ItemRoute>(path: ':date'),
class HomeRoute extends GoRouteData {
  const HomeRoute();
  @override
  Widget build(context) => const HomeScreen();
class HomeScreen extends StatelessWidget {
  const HomeScreen({super.key});
  @override
  Widget build(BuildContext context) {
    final now = DateTime.now();
    return Scaffold(
      appBar: AppBar(
        title: const Text('Home'),
      body: ListView.builder(
        itemBuilder: (context, index) {
          final itemDate = now.add(Duration(hours: index));
          final roundedDate = DateTime(
            itemDate.year,
            itemDate.month,
            itemDate.day,
          return ListTile(
            title: Text(itemDate.toString()),
            onTap: () {
              GoRouter.of(context).go(ItemRoute(roundedDate).location);
class ItemRoute extends GoRouteData {
  const ItemRoute(this.date);
  final DateTime date;
  @override
  Widget build(context) => ItemScreen(date: date);
class ItemScreen extends StatelessWidget {
  const ItemScreen({
    required this.date,
    super.key,
  final DateTime date;
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('Item'),
      body: Center(
        child: Text(date.toString()),
          
Hello @ValentinVignal. Thank you for filing this proposal. I am not sure if removing the 0s is a viable solution unless we are always assuming that no time means 12 am, which is the current way. But what if the use case is to show this information to the i.e. 12 am to the user in the URL? How do you propose that could be handled? One way I see, is to add a feature for custom parsing of URL fields though that would be a large feature I reckon
  waiting for customer response
  The Flutter team cannot make further progress on this issue until the original reporter responds
 label
    Nov 25, 2022
          
@exaby73 I agree that custom parsing of URL fields would solve the issue. I think there is already #110781 for that.

But since DateTime is a type supported "by default" for now, I was wondering if we should consider 2022-11-25%2000%3A00%3A00.000 as a properly parsed parameter or not.
@iapicca Yes, utc unix time would work as much as 2022-11-25%2000%3A00%3A00.000 but it wouldn't be user-friendly either to see 1669454339384 in the URL.
Maybe my case is a bit specific as I only care about the date (year, month, day) and not about the time of the day.

My use case is building a calendar. is building a calendar and I would like to show /my-calendar/2022-11-25 as a URL (or more generally /my-calendar/:date-of-the-viewed-day) when the user sees a specific day.
  waiting for customer response
  The Flutter team cannot make further progress on this issue until the original reporter responds
 label
    Nov 26, 2022
@iapicca Yes, utc unix time would work as much as 2022-11-25%2000%3A00%3A00.000 but it wouldn't be user-friendly either to see 1669454339384 in the URL.
oh sorry I missed that part
          
@ValentinVignal I think changing the way GoRouter is encoding dates (via toString) and decoding it (via parse) is not feasible. Dart unfortunately, doesn't have a Date class, just a DateTime one. Therefore, it makes sense that the time is included. As for how it's shown in the URL, that's the result of URL encoding and can't be changed at all.
since DateTime is a type supported "by default" for now
What's the definition of "supported" here? To me, the support extends to encoding the DateTime to a string and decoding it when parsed. It's only logical that the default string conversion and parsing is used on the DateTime class as using custom formats would require using something like the intl package to format the dates. Then the argument of which locale the dates should be shown in would arise.
Instead of implementing a specific feature for parsing dates, and going back and forth on the right approach to do so, I think #110781 is our best bet for this as it gives much more flexibility for parsing all parameters, not just dates.
As a workaround, may I suggest 2 solutions:
Send a String instead and manually parse it.
Change /my-calendar/:date-of-the-viewed-day to /my-calendar/:year/:month/:day so that the URL can be read as /my-calendar/2022/11/28.
Yes in both these cases, we are not using DateTime, but unfortunately, I do not see a better solution to make this user-friendly enough using DateTime
This is a valid issue, but since I believe that instead of 2 features, one feature (#110781) can kill both birds, I am closing this issue as invalid. If you disagree with my decision, please comment with your reasoning and I can reopen the issue. Thank you :)
What's the definition of "supported" here?
What I meant by that is that go_router_builder explicitly has code to support DateTime in the URL (using toString and tryParse).
https://github.com/flutter/packages/blob/ac1a00b9e5d385042b142745a626f20147c2db5a/packages/go_router_builder/lib/src/type_helpers.dart#L145-L158
For example, Iterable or Set (See #108437) or Color from flutter are not supported types.