Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 18 16:43
    jskeet commented #1311
  • Jan 18 15:26

    jskeet on master

    Update NUnit3TestAdapter and Mi… Change how we run "all but the … (compare)

  • Jan 18 15:26
    jskeet closed #1467
  • Jan 18 15:23
    codecov-io commented #1467
  • Jan 18 15:18
    jskeet synchronize #1467
  • Jan 18 15:16
    codecov-io commented #1467
  • Jan 18 15:07
    jskeet assigned #1467
  • Jan 18 15:07
    jskeet opened #1467
  • Jan 15 17:10
    jskeet commented #1131
  • Jan 15 13:03
    jskeet commented #1311
  • Jan 15 12:49
    artfulsage commented #1311
  • Jan 15 12:48
    artfulsage commented #1311
  • Jan 15 11:49
    jskeet commented #1466
  • Jan 15 11:45
    Youssef1313 commented #1466
  • Jan 15 09:26
    jskeet commented #1466
  • Jan 14 21:42
    jskeet synchronize #1466
  • Jan 14 21:38
    jskeet opened #1466
  • Jan 14 21:22

    jskeet on master

    Add CLDR v36 Windows / IANA zon… (compare)

  • Jan 14 21:22
    jskeet closed #1464
  • Jan 14 21:22
    jskeet closed #1463
Jon Skeet
@jonskeet_twitter
@HEskandari: Depending on the reason for contact, either email me directly (skeet@pobox.com), email the Google group, or file an issue in GitHub.
Hadi Eskandari
@HEskandari
@jonskeet_twitter thanks, I'll send you an email momentarily
Artur Malendowicz
@artur-malendowicz-gain

hello. quick question: wanted to use NodaTime to detect current IANA on iOS (xamarin) - I am based in Poland, but for me using:
DateTimeZoneProviders.Tzdb.GetSystemDefault();

always returns Europe/Zurich

Jon Skeet
@jonskeet_twitter
I suspect that's because there are no differences between Switzerland and Poland "around now" (IIRC, we detect based on offsets for two years ago to two years in the future).
(I assume TimeZoneInfo.Local.Id returns "Local" or something similarly useless? I think we use the ID or name if possible.)
(It might be worth asking about this on GitHub - I actually get notified of changes on GitHub much quicker than on Gitter... and it leaves a more lasting record.)
Stephen A. Imhoff
@Clockwork-Muse
@jonskeet_twitter - Even though Warsaw is +2/+3, and Zurich is +1/+2?
Jon Skeet
@jonskeet_twitter
Hmm... that's odd then.
(Hadn't actually checked.)
@artur-malendowicz-gain: Could you check what DateTime.Now returns on the device? Definitely worth filing a GitHub issue with a lot more information.
Fred Zhang
@falinelli_twitter
Hi, I have a question: what is the biggest year NZD file can reach?
the latest NZD file I got is published on 2019 but it can only reach 2025.
I am wondering if we can get a file that can reach 2050
Jon Skeet
@jskeet
Could you explain what you mean by "it can only reach 2025"? All nzd files should cover all of history. This is probably some problem with your code rather than the nzd file. It's probably best to file a github issue or ask a Stack Overflow question.
Andrew Kondratiuk
@Alantoo
Hi all. I really like NodaTime and would like to use it. But I need some help to find answers to a few questions. It would be awesome if you can help with it. Is it possible to use NodaTime with AspNetCore? I'm trying to recieve query param of type Instant but with no success. It looks like there are no ModelBinder and I can't find it. Environment is: Windows 10, AspNetCore 2.2 and NodaTime 2.4.6. JSON parsing works. But unfortunatelly with query/path/form params does not. Thank you in advance
Jon Skeet
@jonskeet_twitter
These would be better questions for Stack Overflow, including showing exactly what you've tried. Yes, it works fine with ASP.NET Core, but you need to configure Json.NET to use NodaTime.Serialization.JsonNet
Andrew Kondratiuk
@Alantoo
Thank you for quick reply. It might be quick fix. But if does not - sure, I will create question on SO. If you never mind I'll try to explain what problem I got. JSON serialization and deserialization works fine. I can't receive plain arguments (Instant in this case). Exception message told me that there are no ModelBinder. Should I register comething special for it? Thank you again.
Jon Skeet
@jonskeet_twitter
No, please create a question on SO, with example code so it's easy to reproduce, and the exact exception including a stack trace.
Andrew Kondratiuk
@Alantoo
Okay, thanks.
Andrew Kondratiuk
@Alantoo
Hi all. I'm using nodatime beta1 in my project and I got problem with parsing ZonedDateTime. It looks like there are no TypeConverter for it. Instant, OffsetDateTime, LocalDate works great. But for ZonedDateTime I got error: Could not create an instance of type 'NodaTime.ZonedDateTime'. Model bound complex types must not be abstract or value types and must have a parameterless constructor. Is it by design and I should create ModelBinder for it or this is a bug? Thanks in advance
Jon Skeet
@jonskeet_twitter
ZonedDateTime would be tricky to do in a general way - which time zone provider should it use? I admit I didn't spot that it was missing when the TypeConverter PR came in.
I've filed nodatime/nodatime#1407 to track that
Andrew Kondratiuk
@Alantoo
Understood. I'll create ModelBinder for it for now. Thanks.
ekwus
@ekwus

Hey does anyone know if NodaTime Instant serialises/deserialises correctly when using Json.net and ASP.NET Core 3.0 Preview 9? I'm not able to get things to work at all when using the ConfigureForNodatime extension

services.AddMvc().AddNewtonsoftJson((options) => options.SerializerSettings.ConfigureForNodaTime(DateTimeZoneProviders.Tzdb));

and if I just ignore adding the extension I just get 1 January 1970 as the Instant values - looking at Fiddler, the serialisation for the field is empty. Interestingly, Duration does serialise correctly in the same object over the same Http Get.

I'm calling the controller from a Blazor client side app if that makes a differenc too?

Jon Skeet
@jonskeet_twitter
@ekwus: This would be best asked on Stack Overflow. You might want to look at the question slightly earlier in the chat though: https://stackoverflow.com/questions/57753258
ekwus
@ekwus
@jonskeet_twitter Thanks I'll post it on SO. I did see the question above however it answers it for ASP.NE Core 2.2 and the AddJsonOptions extension is gone from 3.0. I've tried a few ways around using it with the AddNewtonsoftJson extension but nothing works. Anyway, I'll put it all on SO to ensure it gets captured for others too. Cheers
ekwus
@ekwus
@jonskeet_twitter Further update. I create a clean ASP.NET Core 3.0 project to push to Github as a reference for the StackOverflow question but the serialisation was working correctly after I figured out the new extensions. Looks like its a setup issue in my other project. I'm also pulling the values from LiteDB in that app so possibly an area for me to look at too. Cheers
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.