Alternativet är humant ([du måste registrera dig för att se länken]).
Kärnan i problemet är vad .. Om du av misstag installerade en databas på en SQL-server med en "datumoffset" på 0, så uppstod ett problem när ett attribut med typen TIME påträffas i databasen, dvs 01.01.0001 10 :30:00 eller datum anges i detta attribut registrerat tomt 01.01.0001 00:00:00. När ett sådant attribut registreras registreras det inte.
På Internet föreslår de att skapa en ny bas med en offset på 2000.
Men jag ville egentligen inte skapa en ny bas. Och ändra sökvägen till databasen för alla användare.
Sedan följde jag vägen, och var är detta värde lagrat i SQL. Hittade och ändrade till 2000 och allt var ok..
Och nu steg för steg var du ska ändra.
Kasta ut alla användare.
UPPMÄRKSAMHET!!!
1. Gör först säkerhetskopiering med hjälp av 1C, dvs. ladda ur den i * .dt
Detta måste göras innan du ändrar "offset"
Om detta inte görs, då i hela din databas, remisser, doc, etc.
där det finns en rekvisita blir datumet till exempel 02.10.0009
VAD ÄR INTE TILLÅT….
Så du har gjort en uppladdning till *.dt
2. Gå till SQL Server Management Studio
Hitta din bas i listan, klicka på plustecknet.
Hitta "Tables"-pappan där och öppna den.
Ett gäng bord kommer att öppnas, gå till botten, hitta bordet
_YearOffset, vi står på den och väljer "Öppet bord" med den högra tangenten, se Fig. 1
Ändra värdet 0 till 2000
Stäng SQL Server Management Studio
3. Gå till konfiguratorn och ladda den tidigare sparade databasen.
Om detta inte görs kommer alla datum att vara med år 0009.
Efter att databasen har laddats ... Du kan gå till 1C och se till att datumen är normala.
Vi ändrade resultatet "datumförskjutning från 0 till 2000"
Ibland händer det att det här alternativet inte kan användas av en eller annan anledning. Sedan finns det ett mer hardcore-alternativ ([du måste registrera dig för att se länken]):
Deklarera TablesAndFields-markören för
VÄLJ objekt.namn som Tabellnamn, kolumner.namn som kolumnnamn
FRÅN dbo.sysobjects som objekt
vänster sammanfoga dbo.syscolumns som kolumner på objects.id = columns.id
där objects.xtype = "U" och columns.xtype = 61
öppna TablesAndFields
WHILE @@ FETCH_STATUS = 0
BEGIN Exec (" uppdatering "+ @Tabellnamn + "
uppsättning " + @ColumnName + " =
""2000-
01-
01 00:00:00"
"
var " + @ColumnName + " >
""3999-
12-
31 23:59:59"
"")
Detta exekveras så länge som föregående hämtning lyckas.
HÄMTA NÄSTA FRÅN TablesAndFields till @TableName, @ColumnName
SLUTET
stäng TablesAndFields
deallokera TablesAndFields
gå
Innan någon manipulation, glöm inte att göra kopior av databaserna!
Problemet har inget med databasen att göra. Om du ställer in en brytpunkt eller går in i en utgång någonstans, bör du kunna se förskjutningen fästas kort efter den här koden:
TestDateAndTime = testDateAndTime.DateTime.Date;
Låt oss bryta ner det här:
- Du började med DateTimeOffset-värde 2008-05-01T08: 06: 32 + 01: 00
- Sedan ringde du DateTime, vilket resulterade i ett DateTime-värde 2008-05-01T08: 06: 32 med DateTimeKind.Unspecified.
- Sedan ringde du Date, vilket resulterade i ett DateTime-värde 2008-05-01T00: 00: 00 med DateTimeKind.Unspecified.
- Du tilldelar resultatet till testDateAndTime, som är av typen DateTimeOffset. Detta anropar en implicit cast från DateTime till DateTimeOffset - som gäller lokal Tidszon... I ditt fall verkar offset för det värdet i din lokala tidszon vara -04: 00, så det resulterande värdet är DateTimeOffset från 2008-05-01T00: 00: 00-04: 00 som du beskrev.
Du sa:
Slutmålet är att helt enkelt ha ett datum utan tids- eller tidszonsförskjutning.
Jo det finns för närvarande inte en inbyggd C #-datatyp, som bara är ett datum utan tid. Det finns en ren datumtyp i System tid paket i corefxlab, men det är inte riktigt redo för en typisk produktionsapplikation än. Det finns LocalDate i Noda Time-biblioteket, som du kan använda idag, men du måste fortfarande konvertera tillbaka till en inbyggd typ innan du sparar till databasen. Så samtidigt är det bästa du kan göra:
- Ändra din SQL Server för att använda datumtypen i fältet.
- I din .NET-kod använder du DateTime med 00:00:00 tid och DateTimeKind.Unspecificed. Du måste komma ihåg att ignorera tidsdelen (eftersom det verkligen finns datum utan lokal midnatt i vissa tidszoner).
- Ändra proptestet till DateTime och inte DateTimeOffset.
I allmänhet, medan DateTimeOffset är lämplig för ett stort antal scenarier (t.ex. tidsstämplar händelser), fungerar det inte bra endast för datumvärden.
jag vill dagens datum med noll offset.
Om du vill verkligen det är som DateTimeOffset, du kan göra:
TestDateAndTime = new DateTimeOffset (testDateAndTime.Date, TimeSpan.Zero);
Jag rekommenderar dock inte att göra detta. Genom att göra det tar du lokal datum för det ursprungliga värdet och påstår sig vara i UTC. Om den ursprungliga offseten är något annat än noll är detta ett falskt påstående. Det kommer att leda till andra fel efteråt eftersom du faktiskt talar om en annan tidpunkt (med ett potentiellt annat datum) än den du skapade.
Relativt ytterligare fråga ställ in i din tavla. Genom att specificera DateTimeKind.Utc ändras det implicita castbeteendet. Istället för att använda den lokala tidszonen används UTC-tid, som alltid har en nollförskjutning. Resultatet är detsamma som den mer explicita synen jag gav ovan. Jag avråder fortfarande från detta av samma skäl.
Tänk på ett exempel som börjar 2016-12-31T22: 00: 00-04: 00. Enligt ditt tillvägagångssätt bör du lagra i databasen 2016-12-31T00: 00: 00 + 00: 00. Det är dock två olika tidpunkter. Den första, normaliserad till UTC, skulle vara 2017-01-01T02: 00: 00 + 00: 00, och den andra, omvandlad till en annan tidszon, skulle vara 2016-12-30T20: 00: 00-04: 00 . Lägg märke till förändringen av datum i konverteringen. Detta är förmodligen inte det beteende du skulle vilja använda i din applikation.
Nästan alla projekt möter problem orsakade av felaktig hantering och lagring av datum och tid. Även om projektet används i samma tidszon kan du fortfarande få obehagliga överraskningar efter att ha gått över till vinter-/sommartid. Samtidigt är få människor förbryllade över implementeringen av den korrekta mekanismen från början, eftersom det verkar som att det inte kan finnas några problem med detta, eftersom allt är trivialt. Tyvärr visar senare verklighet att så inte är fallet.
Logiskt sett kan följande typer av värden relaterade till datum och tid särskiljas:
Låt oss överväga varje objekt separat, inte att glömma.
datum och tid
Låt oss säga att laboratoriet som samlade in materialet för analys är i tidszonen +2 och den centrala grenen, som övervakar att analyser utförs i tid, är i tidszonen +1. Tiden som visas i exemplet noterades under insamlingen av materialet av det första laboratoriet. Frågan uppstår - vilken tidssiffra ska centralkontoret se? Självklart bör programvaran för centralkontoret visa den 15 januari 2014 12:17:15 - en timme mindre, eftersom händelsen hände i det ögonblicket enligt deras klocka.Tänk på en av de möjliga åtgärdskedjorna genom vilka data passerar från klienten till servern och vice versa, vilket gör att du alltid kan visa datum/tid korrekt enligt klientens aktuella tidszon:
- Värdet skapas på kunden, till exempel 2 mars 2016 15 : 13: 36, klienten är i tidszon +2.
- Värdet konverteras till en strängrepresentation för överföring till servern - "2016-03-02T 15 :13:36+02:00”.
- Serialiserade data skickas till servern.
- Servern deserialiserar tiden till ett datum-/tidsobjekt och konverterar den till dess aktuella tidszon. Till exempel, om servern körs på +1, kommer objektet att innehålla den 2 mars 2016 14 :13:36.
- Servern sparar data till databasen, samtidigt som den inte innehåller någon information om tidszonen - de vanligaste datum/tidstyperna vet helt enkelt ingenting om det. Databasen kommer alltså att sparas den 2 mars 2016 14 : 13: 36 i en "okänd" tidszon.
- Servern läser data från databasen och skapar ett motsvarande objekt med värdet 2 mars 2016 14 : 13: 36. Och eftersom servern arbetar i +1-tidszonen kommer detta värde också att tolkas inom samma tidszon.
- Värdet konverteras till en strängrepresentation för överföring till klienten - "2016-03-02T 14 :13:36+01:00”.
- Serialiserad data skickas till klienten.
- Klienten deserialiserar det mottagna värdet till ett datum-/tidsobjekt och konverterar det till dess aktuella tidszon. Om det till exempel är -5, bör det visade värdet vara 2 mars 2016 09 :13:36.
- Tiden på klienten kan genereras utan tidszon alls - till exempel DateTime skriv in .NET med DateTimeKind.Unspecified.
- Serialiseringsmotorn kan använda ett format som inte inkluderar tidszonsförskjutningen.
- När man deserialiserar till ett objekt kan tidszonförskjutningen ignoreras, särskilt i "gör-det-själv" deserializers - både på servern och på klienten.
- När man läser från en databas kan ett datum/tidsobjekt bildas utan tidszon alls - t.ex. skriv DateTime i .NET med DateTimeKind.Unspecified. Dessutom är det i praktiken exakt vad som händer med DateTime i .NET om du inte uttryckligen anger en annan DateTimeKind direkt efter korrekturläsning.
- Om applikationsservrarna som arbetar med den delade databasen är i olika tidszoner kommer det att uppstå allvarlig förvirring om tidsförskjutningar. Datum/tidsvärdet som skrivs till databasen av Server A och läses av Server B kommer att skilja sig markant från samma ursprungliga värde skrivet av Server B och läst av Server A.
- Att flytta applikationsservrar från en zon till en annan kommer att resultera i feltolkning av redan lagrade datum-/tidsvärden.
Reglerna för omräkning till sommar-/vintertid är strängt taget varierande. Olika länder kan ibland ändra sina regler, och dessa ändringar bör införlivas i förväg i systemuppdateringarna. I praktiken har vi upprepade gånger stött på situationer med felaktig funktion av denna mekanism, som som ett resultat löstes genom att installera snabbkorrigeringar eller operativ system, eller använda tredjepartsbibliotek. Sannolikheten för att samma problem återkommer är inte noll, så det är bättre att ha ett garanterat sätt att undvika dem.
Med hänsyn till de överväganden som beskrivits ovan kommer vi att formulera den mest tillförlitliga och enkla metoden för överföring och lagring av tid: på servern och i databasen måste alla värden föras till UTC-tidszonen.
Tänk på vad denna regel ger oss:
- När data skickas till servern måste klienten passera tidszonsoffset så att servern korrekt kan konvertera tiden till UTC. Ett alternativ är att tvinga kunden att göra denna konvertering, men det första alternativet är mer flexibelt. När klienten tar emot data tillbaka från servern kommer klienten att översätta datum och tid till sin lokala tidszon, med vetskap om att han i alla fall kommer till tiden i UTC.
- I UTC finns det inga sommar- och vinterövergångar, därför kommer problemen i samband med detta att vara irrelevanta.
- På servern, när du läser från databasen, behöver du inte konvertera tidsvärdena, du behöver bara uttryckligen ange att det motsvarar UTC. I NET, till exempel, kan detta uppnås genom att ställa in DateTimeKind för tidsobjektet till DateTimeKind.Utc.
- Skillnaden i tidszoner mellan servrar som arbetar med en gemensam databas, såväl som överföringen av servrar från en zon till en annan, kommer inte att påverka riktigheten av mottagna data på något sätt.
- Gör serialiserings- och deserialiseringsmekanismen så att datum/tidsvärden är korrekt översatta från UTC till den lokala tidszonen och vice versa.
- Se till att deserializern på serversidan skapar datum-/tidsobjekt i UTC.
- Se till att när du läser från databasen skapas datum-/tidsobjekt i UTC. Den här klausulen tillhandahålls ibland utan kodändringar - det är bara så att systemets tidszon på alla servrar är inställd på UTC.
- Systemkraven behöver inte visas lokal tid och/eller tidszonens förskjutning exakt som den lagrades. Till exempel i flygbiljetter ska avgångs- och ankomsttider skrivas ut i den tidszon som motsvarar flygplatsens läge. Eller om servern skickar för att skriva ut fakturor skapade i olika länder, var och en ska sluta med en lokal tid, inte konverterad till serverns tidszon.
- Alla datum- och tidsvärden i systemet är "absoluta" - dvs. beskriv en tidpunkt i framtiden eller det förflutna som motsvarar ett enda värde i UTC. Till exempel, "lanseringen av bärraketen ägde rum kl 23:00 Kiev-tid" eller "mötet kommer att hållas från 13:30 till 14:30 Minsk-tid." I olika tidszoner kommer siffrorna för dessa händelser att vara olika, men de kommer att beskriva samma ögonblick i tiden. Men det kan hända att kraven för programvara antyda "relativ" lokal tid i vissa fall. Till exempel, "det här TV-programmet kommer att visas från 9:00 till 10:00 i alla länder där det finns en filial till TV-kanalen." Det visar sig att showen av programmet inte är en händelse, utan flera, och potentiellt alla kan inträffa med olika tidsintervall på en "absolut" skala.
| .NETTO | DatumTimeOffset |
| Java | org.joda.time.DateTime, java.time.ZonedDateTime |
| MS SQL | datumtidsförskjutning |
| Oracle, PostgreSQL | TIDSTÄMPEL MED TIDZON |
| MySQL | — |
Brott mot det andra villkoret - mer svårt fall... Om denna "relativa" tid behöver lagras helt enkelt för visning, och det inte finns någon uppgift att bestämma det "absoluta" ögonblicket i tiden när en händelse har inträffat eller kommer att inträffa för en given tidszon, räcker det bara att inaktivera tidskonvertering . Användaren angav till exempel starten av sändningen för alla filialer av TV-bolaget den 25 mars 2016 klockan 9:00, och den kommer att sändas, lagras och visas i detta formulär. Men det kan hända att någon schemaläggare automatiskt måste utföra speciella åtgärder en timme före starten av varje program (skicka aviseringar eller kontrollera förekomsten av vissa data i TV-bolagets databas). Att tillförlitligt implementera en sådan schemaläggare är inte en trivial uppgift. Låt oss säga att planeraren vet vilken tidszon varje gren befinner sig i. Och ett av länderna där det finns en filial, efter ett tag bestämmer sig för att ändra tidszonen. Fallet är inte så sällsynt som det kan tyckas - för detta och de föregående två åren har jag räknat till mer än 10 sådana händelser (http://www.timeanddate.com/news/time/). Det visar sig att antingen måste användarna hålla sina tidszonsbindningar uppdaterade, eller så måste schemaläggaren automatiskt ta denna information från globala källor som Google kartor Tidszon API. Jag förbinder mig inte att erbjuda en universell lösning för sådana fall, jag noterar bara att sådana situationer kräver seriösa studier.
Som du kan se från ovan, det finns inget enskilt tillvägagångssätt som täcker 100 % av fallen... Därför måste du först tydligt förstå från kraven vilka av ovanstående situationer som kommer att vara i ditt system. Troligtvis kommer allt att begränsas till den första föreslagna metoden med lagring i UTC. Tja, de beskrivna exceptionella situationerna avbryter det inte, utan lägger helt enkelt till andra lösningar för speciella fall.
Datum utan tid
Låt oss säga att vi har hittat rätt visning av datum och tid, med hänsyn till klientens tidszon. Låt oss gå vidare till datum utan tid och exemplet som anges för detta fall i början - "det nya avtalet träder i kraft den 2 februari 2016". Vad händer om du använder samma typer och samma mekanism för sådana värden som för "vanliga" datum med tider?Inte alla plattformar, språk och DBMS har typer som endast lagrar datumet. Till exempel, i .NET finns bara typen DateTime, det finns ingen separat "bara Date". Även om endast datumet angavs när ett sådant objekt skapades, är tiden fortfarande närvarande, och den är lika med 00:00:00. Om vi översätter värdet "2 februari 2016 00:00:00" från zonen med en offset på +2 till +1 får vi "1 februari 2016 23:00:00". För exemplet ovan skulle detta motsvara det faktum att i en tidszon kommer det nya kontraktet att träda i kraft den 2 februari och i en annan - den 1 februari. Ur juridisk synvinkel är detta absurt och så ska det naturligtvis inte vara. Den allmänna regeln för "rena" datum är extremt enkel - sådana värden bör inte konverteras i något steg av att spara och läsa.
Det finns flera sätt att undvika konvertering för datum:
- Om plattformen stöder en typ som representerar ett datum utan tid, bör det användas.
- Lägg till en speciell funktion till metadata för objekt som kommer att berätta för serializern det för givet värde tidszonen bör ignoreras.
- Skicka datumet från klienten och tillbaka som en sträng och lagra det som ett datum. Detta tillvägagångssätt är obekvämt om klienten inte bara behöver visa datumet, utan också utföra några operationer på det: jämförelse, subtraktion, etc.
- Skicka och lagra som en sträng och konvertera till ett datum endast för klientens språkformatering. Det har ännu fler nackdelar än det tidigare alternativet - till exempel om delarna av datumet i den lagrade strängen inte är i ordningen "år, månad, dag", kommer det att vara omöjligt att göra en effektiv indexerad sökning över datumet räckvidd.
Tidsintervall
Med lagring och bearbetning av tidsintervall är allt enkelt: deras värde beror inte på tidszonen, så det finns inga speciella rekommendationer här. De kan lagras och överföras som ett antal tidsenheter (heltal eller flyttal, beroende på vilken precision som krävs). Om andra precision är viktig - då som antalet sekunder, om millisekunder - då som antalet millisekunder osv.Men beräkningen av intervallet kan ha fallgropar. Anta att vi har något exempel på C #-kod som räknar tidsintervallet mellan två händelser:
DateTime start = DateTime.Now; // ... DateTime end = DateTime.Now; dubbla timmar = (slut - start) .TotalHours;
Vid första anblicken är det inga problem här, men så är inte fallet. För det första kan det finnas problem med att enhetstesta sådan kod, men vi ska prata om det lite senare. För det andra, låt oss föreställa oss att det första ögonblicket föll på vintertid och det sista ögonblicket föll på sommartid (till exempel mäts antalet arbetstimmar på detta sätt och arbetare har ett nattskift).
Anta att koden fungerar i en tidszon där sommartid 2016 inträffar på natten den 27 mars, och låt oss simulera situationen som beskrivs ovan:
DateTime start = DateTime.Parse ("2016-03-26T20: 00: 15 + 02"); DateTime end = DateTime.Parse ("2016-03-27T05: 00: 15 + 03"); dubbla timmar = (slut - start) .TotalHours;
Denna kod kommer att resultera i 9 timmar, även om det faktiskt har gått 8 timmar mellan dessa ögonblick. Du kan enkelt verifiera detta genom att ändra koden så här:
DateTime start = DateTime.Parse ("2016-03-26T20: 00: 15 + 02"). ToUniversalTime (); DateTime end = DateTime.Parse ("2016-03-27T05: 00: 15 + 03"). ToUniversalTime (); dubbla timmar = (slut - start) .TotalHours;
Därav slutsatsen - alla aritmetiska operationer med datum och tid måste göras med antingen UTC-värden eller typer som lagrar information om tidszonen. Och sedan översätta tillbaka till lokala om det behövs. Ur denna synvinkel kan det ursprungliga exemplet enkelt fixas genom att ändra DateTime.Now till DateTime.UtcNow.
Denna nyans beror inte på en specifik plattform eller språk. Här är en liknande Java-kod med samma nackdel:
LocalDateTime start = LocalDateTime.now (); // ... LocalDateTime end = LocalDateTime.now (); långa timmar = ChronoUnit.HOURS.between (start, slut);
Det är också enkelt att fixa - till exempel genom att använda ZonedDateTime istället för LocalDateTime.
Schemalägg schemalagda händelser
Att schemalägga schemalagda händelser är en mer komplex situation. En universell typ som låter dig lagra tidtabeller i standardbibliotek Nej. Men en sådan uppgift uppstår inte så sällan, så färdiga lösningar kan hittas utan problem. Ett bra exempelär ett cron-schemaläggarformat som används i en eller annan form av andra lösningar, till exempel Quartz: http://quartz-scheduler.org/api/2.2.0/org/quartz/CronExpression.html. Den täcker nästan alla schemaläggningsbehov, inklusive alternativ för andra fredagen i månaden.I de flesta fall är det ingen mening att skriva din egen schemaläggare, eftersom det finns flexibla tidstestade lösningar, men om det av någon anledning finns ett behov av att skapa din egen mekanism, så kan åtminstone schemaformatet lånas från cron.
Utöver de rekommendationer som beskrivs ovan om lagring och bearbetning av olika typer av tidsvärden, finns det flera andra som jag också skulle vilja prata om.Först om att använda statiska klassmedlemmar för att få aktuell tid - DateTime.UtcNow, ZonedDateTime.now (), etc. Som nämnts kan användningen av dem direkt i koden allvarligt komplicera enhetstestning, eftersom det är omöjligt att ersätta den nuvarande tiden utan speciella mock-ramverk. Därför, om du planerar att skriva enhetstester, bör du se till att implementeringen av sådana metoder kan ersättas. Det finns åtminstone två sätt att lösa detta problem:
- Markera IDateTimeProvider-gränssnittet med en enda metod som returnerar den aktuella tiden. Lägg sedan till ett beroende till detta gränssnitt i alla kodenheter där du behöver få aktuell tid. Under normal körning av programmet kommer "default"-implementeringen att injiceras på alla dessa platser, vilket returnerar den verkliga aktuella tiden, och i enhetstester - alla andra nödvändiga implementeringar. Denna metod är den mest flexibla när det gäller testning.
- Gör din egen statiska klass med en metod för att få aktuell tid och möjligheten att installera valfri implementering av denna metod utifrån. Till exempel, i fallet med C #-kod, kan denna klass exponera egenskapen UtcNow och SetImplementation (Func
impl). Användande statisk egenskap eller metoden för att få aktuell tid eliminerar behovet av att uttryckligen skriva beroendet av det extra gränssnittet överallt, men ur OOP-principernas synvinkel är det inte idealisk lösning... Men om det tidigare alternativet av någon anledning inte är lämpligt, kan du använda detta.
Den andra nyansen med att få den aktuella tiden är det kunden kan inte lita på... Den aktuella tiden på användarnas datorer kan skilja sig mycket från den verkliga, och om det finns logik kopplat till den kan denna skillnad förstöra allt. Alla platser där det finns behov av att få aktuell tid bör om möjligt utföras på serversidan. Och, som nämnts tidigare, måste alla aritmetiska operationer med tid utföras antingen i UTC-värden eller med hjälp av typer som lagrar tidszonsförskjutningen.
Och en sak till som jag skulle vilja nämna är ISO 8601-standarden, som beskriver datum- och tidsformat för informationsutbyte. I synnerhet måste strängrepresentationen av datum och tid som används vid serialisering överensstämma med denna standard för att undvika potentiella kompatibilitetsproblem. I praktiken är det extremt sällsynt att du måste implementera formatering själv, så själva standarden kan vara användbar främst i informationssyfte.
Taggar: Lägg till taggar
