Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 24 12:52
    jskeet commented #6
  • Oct 24 12:17
    neiesc commented #6
  • Oct 22 06:02

    jskeet on master

    Update TZDB to 2020d (compare)

  • Oct 22 06:02
    jskeet closed #1581
  • Oct 22 05:58
    jskeet assigned #1582
  • Oct 22 05:58
    jskeet opened #1582
  • Oct 22 05:56

    jskeet on 3.0.3

    (compare)

  • Oct 22 05:56

    jskeet on 3.0.x

    Update to TZDB 2020d for releas… (compare)

  • Oct 22 05:55

    jskeet on 2.4.11

    (compare)

  • Oct 22 05:55

    jskeet on 2.4.x

    Update to TZDB 2020d for releas… (compare)

  • Oct 22 05:34
    jskeet opened #1581
  • Oct 17 07:18

    jskeet on master

    Update TZDB to 2020c (compare)

  • Oct 17 07:18
    jskeet closed #1580
  • Oct 17 06:28
    codecov-io commented #1580
  • Oct 17 06:24
    jskeet opened #1580
  • Oct 17 06:16

    jskeet on 3.0.2

    (compare)

  • Oct 17 06:16

    jskeet on 3.0.x

    Update to TZDB 2020c for releas… (compare)

  • Oct 17 06:16

    jskeet on 2.4.10

    (compare)

  • Oct 17 06:16

    jskeet on 2.4.x

    Update to TZDB 2020c for releas… (compare)

  • Oct 15 15:34
    jskeet closed #1576
Andrew Kondratiuk
@Alantoo
Hello to all. I'm migrating my project to EF Core 3. As I see currently I can use instance of Instant (local variable for example) or SystemClock.Instance.GetCurrentInstant() in my queries. Is it possible to use an injected IClock or this is by deisgn to not allow it? Thank you in advance
Jon Skeet
@jonskeet_twitter
@Alantoo: Are you using a particular EF Core plug-in library? It could be converting SystemClock.Instance.GetCurrentInstant() into SQL to fetch the current time on the server. I'm afraid I don't really understand enough about what your context to help you - I'd strongly suggest asking a new question on Stack Overflow with more detail.
Andrew Kondratiuk
@Alantoo
@jonskeet_twitter Yes, I'm using it. It works great with SystemClock.Instance.GetCurrentInstant(). It would be awesome to have ability to use instance of IClock in queries as well. It can help a bit in unit tests. I just would like to know if there any plans to implement it or maybe it not works only with EF Core 3 and it will be fixed later? Thank you for your answers
Jon Skeet
@jonskeet_twitter
Again, I don't have enough context here. Without even knowing which package you're using, I can't possibly know whether there's a plan to implement the use of arbitrary clocks - but I wouldn't expect so, given that you can't generate SQL for "what's the time that some arbitrary IClock implementation would return". Please bear in mind that the NodaTime package itself doesn't know anything about EF Core, so I'm pretty sure you're using some other package - I strongly recommend finding the GitHub repo for that project, and asking a question there.
Andrew Kondratiuk
@Alantoo
Understood. Thanks for answer
JT
@Hawxy
I have a conceptual question regarding type usage that is mostly covered by the docs but I'd still like clarification on. For context, we have a SPA that will be sending ISO timestamps to our backend via the Luxon library. Users will be specifying "something happened at this datetime" and "something needs to happen by this datetime". As far as I can tell, the guidelines are "Use Instant if you want to represent something happened at a point in time and then convert to a local version on the client", however via Luxon we'll have the offset & IANA timezone of the user, so should we store a OffsetDateTime + TimeZone anyways? When the data is sent back to the client, it'll be parsed by Luxon into the user's local timezone (per https://moment.github.io/luxon/docs/manual/zones.html#strings-that-specify-an-offset) and displayed. I'm trying to figure out if there'd be any functional difference between the two options (ie Daylight savings, auditing). Right now I'm leaning towards the latter as it seems like it'd be useful for timing notifications correctly on the server when dealing with daylight savings?
Stephen A. Imhoff
@Clockwork-Muse

so should we store a OffsetDateTime + TimeZone anyways?

For which? You have two different things there.
For a logged event, the timezone is entirely irrelevant. You shouldn't be dealing with future notifications from this. Use Instant.
For a future event, humans usually like to schedule things in terms of their local timezone, and most often want to keep the local time if the zone rules change. Use ZonedDateTime.

Stephen A. Imhoff
@Clockwork-Muse

Persisting to a database is a little more interesting. Assuming SQL Server...
You can usually get away with just a DATETIME2 for Instant, but if you do be explicit (ie, via column name) that the value is absolute/UTC. That is, consider the timezone the "unit" of the timestamp. You can also use custom types to more directly create a "raw" value (say, seconds+nanoseconds).
For future dates, generally you're going to want to use a DATETIMEOFFSET with a string for the timezone id. I recommend you ignore the timezone functions in the database, and perform all timezone-related math in the application layer:

  1. You're using IANA ids, and if you're on Windows, they ain't there!
  2. Even if you were hosting SQL Server on Linux, and it used the IANA ids, you now have two separate instances of the rules database.

That last point should also make you cautious when dealing with distributed applications and cloud hosting: your application may be updated unevenly, and you may not even be in control of the system ruleset (packaging it with your application may help). Note you will have to be prepared for mismatches between the stored offset and the "correct" offset from the ruleset.

As a side note, the current record between notification of a DST change and it going into effect is... ~1 Day (Haiti). Multiple sub-week examples exist. In some cases there will not be sufficient time for a rule update to be published.
JT
@Hawxy
Thanks, I think that clarifies it for me. We're using Postgres + Marten with Nodatime support so storage isn't a problem.
JT
@Hawxy
Use ZonedDateTime correct me if I'm wrong, but afaik this type cannot be parsed out of the box in a controller and would require a custom formatter/parser on the client which is why I mentioned ODT + IANA stored separately.
Stephen A. Imhoff
@Clockwork-Muse

Ah, I meant more that it's the correct domain type to use server side.

From the look of it, yes, you'd need a custom format string on the client side - fromFormatshould be all you need to be able to match the default output from NodaTime. (fromISO probably doesn't do what you want, given the examples given).
Note that this does mean you potentially have two different rulesets in use at a single time.

JT
@Hawxy
Yep, got it working. I was creating the wrong pattern on the front-end, trying to conform with the value I was seeing when a ZonedDateTime is converted to a string 2019-11-08T09:43:52 Australia/Perth (+08) rather than what was stated on the serialize page 2019-11-08T09:59:52+08:00 Australia/Perth. If someone else is using Luxon and comes across this, the correct pattern to use is "yyyy-MM-dd'T'HH:mm:ssZZ z"
Den
@chakaponden
Hi, guys! Nodatime is based on Joda-time, right?
Ohh, found, it
it's just a port
Jon Skeet
@jonskeet_twitter
No, it's not "just a port". It's a totally separate project, with a fairly different API. The initial code was based on Joda Time, but with a lot of Joda Time's public API made internal - and the remaining public API significantly overhauled. Then over time we refactored a lot of now-internal code as well. So it has a lot in common with Joda Time, but I don't think it's now accurate to describe it as a port.
Douglas Melo
@Linkhi
Hi, Has anyone had this problem?
Time zone Etc / GMT + 3108611 is unknown to source TZDB: 2019c
Jon Skeet
@jskeet
@Linkhi: I'm not surprised that time zone doesn't work, but what is supplying that as a time zone ID in the first place?
Douglas Melo
@Linkhi
@jskeet Sorry, actually the problem is occurring in GeoTimeZone and not in NodaTime. Thank you jskeet
Slaviusz
@Slaviusz
Hey, I'm migrating from netcoreapp2.2 to netcoreapp3.1 and having issues with TZDB conversion failing in EF Core queries. There used to be services.AddJsonOptions(options => options.JsonSerializerOptions.ConfigureForNodaTime(Tzdb);) but it's gone in .NetCore3.1. Any clue? Thanks
Jon Skeet
@jskeet
Please check Stack Overflow - basically you need to use the new NodaTime.Serialization.SystemTextJson package, but I can't give more details right now.
Ben
@explorer_ben_twitter
Hi, I've been trying to work out the best way to solve my issue, but to no avail - I've got existing data in a format like "2020-03-06T18:00:33.0367312+00:00" which I was deserialising to datetime. I've since switched to using Instants for the same fields, and the deserialisation is no longer working, as it can't parse to Instant with the offset. (example error: '2020-03-07T03:24:24.9011659^+00:00'. (^ indicates error position.)) I believe I've set up Noda Time and the Json serialiser settings correctly. The old data unfortunately can't be modified, and new data is saved as Instants. Is there a way to deserialise either into an Instant?
Ben
@explorer_ben_twitter
Should I just use OffsetDateTime as the type instead of Instant? It'll parse the old data and Instants.
Jon Skeet
@jonskeet_twitter
Yes, I would suggest using OffsetDateTime, at least for the serialization. You can convert to an instant afterwards if you need to.
Ben
@explorer_ben_twitter
Thanks! And thanks for your tireless efforts in the community :)
Matteo
@Franklin89
Hi Guys, I am using NodaTime for the first time in my ASP.NET Core Application using Razor Pages. It is working great on the backend side and I am moving forward fast. But I would like to have your insights for the model binding. Should I be using NodaTime Types in my models and QueryString? Because at the moment if I use a LocalDate as a parameter on my OnGet the application crashes...any hints or samples about BestPractices would be appreciated :-)
Stephen A. Imhoff
@Clockwork-Muse
@Franklin89 Maybe this way?
Matteo
@Franklin89
@Clockwork-Muse That would mean implementing custom model binders for each NodaTime Type that I am using...I saw that post, thought there must be some way with writing less code
Kjetil Klaussen
@bulldetektor
Trying to figure out how to add NodaTime Json serialization to a Blazor web assembly project, but I just can't figure out how this is suppose to be done. From what I can see, the way to configure Json settings in net core 3 is to call the services.AddMvcCore().AddJsonOptions(...). But I can't see any extension method for JsonOptions in NodaTime.Serialization.JsonNet? (https://github.com/nodatime/nodatime.serialization/blob/master/src/NodaTime.Serialization.JsonNet/Extensions.cs). What am I missing?
Jon Skeet
@jonskeet_twitter
Could you ask this as a Stack Overflow question or on the serialization repo? I've been actively trying to wind this down as a comms platform, given that any time spent answering someone here is wasted in terms of future people with the same problem.
Kjetil Klaussen
@bulldetektor
@jonskeet_twitter sure!
Didirik
@Didirik
Hi, please, I couldn't find anywhere in documentation, if nodatime supports non-fixed dst timezone transition rules. E.g. info, that for actual system timezone, daylight saving time starts for example at last Sunday in March. Instead of fixed transition time, eg. March 29, 2020. Thank you in advance :)
Stephen A. Imhoff
@Clockwork-Muse
@Didirik - I'm not aware of any real-world DST transition rule that takes place on a specific calendar day each year (there could be some, though). Almost all of them take the form of "nth <n> day in <month>".
I'm less sure about "last" (because that can vary between 4th/5th for some months), but assume it can be. For that matter, I'm relatively certain the rules can be more complicated than just "last".
Jon Skeet
@jskeet
@Didirik: We support the IANA time zone database, which has a bunch of different rules. If you have a more concrete description of what you're trying to, I suggest you ask on Stack Overflow, raise a GitHub issue, or email the mailing list - our experience is that Gitter isn't ideal as a support platform when there's relatively little traffic.
Kevin Avignon
@Kavignon

Hi!

I'm a NodaTime newcomer with a question. Is it possible to convert a time zone provided as a string (ex: "UTC + 4") and convert it to a NodaTime type? I'm looking at the documentation and I can't find my way around. Any help would be greatly appreciated, even if it's just pointing me in the right direction ^^

Read the above comment from @jskeet which lead to me opening an issue on the GitHub repo: nodatime/nodatime#1576
Stephen A. Imhoff
@Clockwork-Muse