wire DateTime<Utc>

[Roms1383]

Hi, I would like to provide the necessary to allow for sending e.g. chrono::DateTime<chrono::Utc> over FFI.
I'm stuck at the moment, below are the steps I already followed :

opening a PR

I first considered contributing directly to flutter_rust_bridge, since a DateTime<Utc> inherently all boils down to a i64, but changed my mind when browsing chrono's documentation since there's considerations about the aforementioned i64 being a timestamp in seconds / milliseconds / microseconds / nanoseconds ? And probably different users have different requirements.

manually code-generating

So, naturally I then came to mimic the code generator by basically writing the boilerplate by hand, implementing Wire2Api<T>, creating wire_DateTimeUtc, etc. Which quickly turns into a dead-end since I shouldn't touch any generated file (e.g. to add required methods in bridge_generated.dart to class NativeImpl extends FlutterRustBridgeBase<NativeWire> implements Native). Then I wondered maybe dart code would in fact be auto-generated, but of course I got caught by the compiler since DateTime<Utc> is an external type.

mirroring

Which of course led me to try to provide a wrapper to DateTime<Utc> with #[frb(mirror)] annotation.
Here I also faced a dead-end since at its deepest, DateTime<Utc> contains an internal unexposed struct, namely DateImpl.

#[frb(mirror(chrono::DateTime<chrono::Utc>))]
pub struct DateTimeUtc {
    pub datetime: chrono::NaiveDateTime,
    pub offset: chrono::Utc,
}

#[frb(mirror(chrono::NaiveDateTime))]
pub struct NaiveDateTime {
    pub date: chrono::NaiveDate,
    pub time: chrono::NaiveTime,
}

pub struct NaiveDate {
    pub ymdf: // 💥 this type is not exposed
}

---

To be honest, I'm running out of ideas. Is there an idiomatic way to do it ?
So far I create intermediate structs all over the place (converting DateTime<Utc> to e.g. a RFC3339 compliant String) but it's a bit cumbersome.

[fzyzcjy]

since there's considerations about the aforementioned i64 being a timestamp in seconds / milliseconds / microseconds / nanoseconds ? And probably different users have different requirements.

IMHO we can generate the DateTime in Dart. It is in the standard library so everyone is using it. https://api.dart.dev/stable/2.18.0/dart-core/DateTime-class.html

Btw for a duration: Duration in Dart standard library.

Looking at DateTime's source code, it is implemented as:

  /// The value of this DateTime.
  ///
  /// The content of this field is implementation dependent. On JavaScript it is
  /// equal to [millisecondsSinceEpoch]. On the VM it is equal to
  /// [microsecondsSinceEpoch].
  final int _value;

So, naturally I then came to mimic the code generator by basically writing the boilerplate by hand, implementing Wire2Api, creating wire_DateTimeUtc, etc.

Maybe we do not need to do that hard! Just convert it to i64 (or u64 maybe?) and we are done! Probably this is just a short PR, and utilize the "delegate". Just like how we treat String via Vec<u8>.

[Roms1383]

Ok great, I'll give it another try in the coming 2 weeks!

[fzyzcjy]

Looking forward to the PR!

[Roms1383]

IMHO we can generate the DateTime in Dart. It is in the standard library so everyone is using it. https://api.dart.dev/stable/2.18.0/dart-core/DateTime-class.html

Well, I had exactly the same idea initially.

---

Ok, actually the choice of seconds / milliseconds / microseconds / nanoseconds unit implies both:

precision

more decimals, more precision: which can be useful for e.g. timestamp-based data syncing mechanism

length of the range in time that it can ultimately represents

the larger the unit, the more date one can represent further in the future or earlier in the past (relative to January 1, 1970 UTC).
which is exactly what is explained in the Rust methods timestamp, timestamp_millis, timestamp_micros and timestamp_nanos, roughly :

• seconds: ~584 Billion years
• milliseconds: ~584 Million years
• microseconds: ~584 Thousand years
• nanoseconds: ~584 years

But as the documentation in chrono states, it's rarely a concern.

So, of course, if implemented in flutter_rust_bridge it has to be opinionated.

---

/// The content of this field is implementation dependent. On JavaScript it is
/// equal to [millisecondsSinceEpoch]. On the VM it is equal to
/// [microsecondsSinceEpoch].

Good point! I'd go with what Dart VM expects, so the microseconds unit.
There's also the consideration of leap/non-leap microseconds, but it's probably best to stick with non-leap unit anyway.

---

Maybe we do not need to do that hard! Just convert it to i64 (or u64 maybe?) and we are done!

u64 generally implies it could represent twice the length of time in the future, but none in the past (relative to January 1, 1970 UTC). Are there some benefits to using it instead of i64 @fzyzcjy ? (performances, ser/de ?).
Otherwise chrono uses i64 and, as you pointed out, Dart uses int.

---

Probably this is just a short PR, and utilize the "delegate". Just like how we treat String via Vec.

Ok, I definitely need to look into the delegate!

[fzyzcjy]

There's also the consideration of leap/non-leap microseconds, but it's probably best to stick with non-leap unit anyway.

dart-lang/sdk#3763 Looks like Dart at least does not have very thorough support on leap seconds. So we can ignore it as well.

The main goal should be: The time generated in Rust should be the same as the time generated in Dart, if both of them are called at the same time. As long as that is true, I guess most people will be happy.

but none in the past (relative to January 1, 1970 UTC).

You are right, i64 is better. I have suggested u64 b/c at that time I was thinking about Snowflake IDs, which, surely, should be positive as ID are usually non-negative, so all timestamps within Snowflake IDs are positive. But surely (real) time can be negative :)